Re: fixed time slices?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Implementation of KeWaitFor* and KeSetEvent (and other signals) doesn't
require kernel to periodically check if a thread changes its state to
runnable.

A synch object has a list of threads currently waiting on it. As a part of
signalling the object, the dispatcher moves the threads into ready-to-run
list, and at this time checks if thread switch is necessary.

"Jan Bruns" <testzugang_janbruns@xxxxxxxx> wrote in message
news:4684f00d$0$23143$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes, the thread obviously has to wait until kernel checks if it has
become runnable.

This hasn't anything to do with hardware's timer resolution
I don't remeber exactly, but the link below talks about ~1.2MHz
timers available on IBM compatible PCs:
http://www.qzx.com/pc-gpe/pit.txt

Also, it doesn't have to do with the overall timeslice the kernel
grants if there's nothing special needed.

It's most likely some slice&subslice scheme, somehow similar to
for example USB's frame&microframe scheme.

Obviously the kernel prefers to have timing-based events
sampled at a low tick-frequency, instead of growing a high
resolution chronological event list.

Gruss

Jan Bruns



"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> schrieb im Newsbeitrag
news:eUK4ALguHHA.5036@xxxxxxxxxxxxxxxxxxxxxxx
Sleep(1) will sleep at least one hardware timer tick, which can be
changed
by timeBeginPeriod down to 1 ms. This is what you observe, no matter that
you elevate the thread priority. You see what you're supposed to get:
1000
timer ticks. (actually with 1 ms you get 2000 timer ticks, most likely
because of rounding errors when miliseconds get converted to actual timer
resolution).

Again: Your thread does NOT have to wait until dispatcher timeslice ends.
Because it runs on elevated priority, it gets CPU immediately after the
sleep timer expires, which depends on the hardware timer tick resolution.

You can easily measure the dispatcher timeslice by running two threads
and
querying performance counter all the time. You will see when you get
large
gaps in readings, this means the thread was preempted. I leave this
exercise
to you.

"Jan Bruns" <testzugang_janbruns@xxxxxxxx> wrote in message
news:4681fa9b$0$14873$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
But the actual behaviour on my computer is diffrent from that.

WF?O and Sleep seem to only return on the beginning of a new
time-slice, except if the event already was signaled on the call.
If the event wasn't signaled, lower priority threads get to run,
and aren't interupted until the end of their slice.

On my computer,

setThreadPriority(realtime); for i := 1 to 1000 do sleep(1);

takes 1000*tick_period to run (normally 15s). This also applies
to WFSO using an event that gets signaled just *after* WFSO
started to block execution.

If I call timeBeginPeriod(1) before the above sniplet, it takes
only about 2 seconds to run, instead of 15, and the same thing
applies to WFSO again, if the event was set 1ms after WFSO
starts to block execution.

So obviously the mmTimer HAL has influence on the kernel's
scheduling intervalls.

This doen't mean that "slice" in the sense of overall dividing
CPU-resources to threads changes.

Gruss

Jan Bruns









"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> schrieb im Newsbeitrag
news:eqwzbEHuHHA.1120@xxxxxxxxxxxxxxxxxxxxxxx
Hardware timer interrupts can be programmed by the HAL for different
frequency, depending on ExSetTimerResolution. But dispatcher (thread
scheduler) "tick" stays the same. This means that ready-to-run threads
of
_equal_ current priority will always be switched at the same intervals.

NEVERTHELESS, as soon as a higher priority thread becomes ready to run,
it
will preempt any lower priority thread. Preemption doesn't have to wait
until thread time slice ends. Scheduler "ticks" (relatively constant)
only
mean to do time-slicing among same priority threads. Hardware timer
interrupts is what actually fires any scheduled timers and tracks
Sleep()
and WFSO() timeouts, and they may have higher (variable) frequency.
Some
systems may also provide high-resolition interval timer, spec designed
by
Intel around 2002(?).

"m" <m@xxx> wrote in message
news:uw328w$tHHA.1768@xxxxxxxxxxxxxxxxxxxxxxx

AFAIK the scheduler does not behave this way but if the scheduler
planed
a
timer interrupt for a specific delay for the purpose of changing tasks
pre-emptivly, then that is just the end of the low-priority thread's
time
slice. In this case, the scheduler would not detect that a higher
priority thread was ready to run, but would _know_ that said thread
would
be ready to run and adjusted the time slices of other threads
accordingly.



This example only makes sense in the case of simple Sleep(n) calls
because
the scheduler can only _know_ when a thread will become ready to run
if
there is a fixed or known delay. Since even the relatively simple
call
SleepEx(n, true) does not have a fixed or known delay, the scheduler
cannot make any assumptions about how best to optimize the timer
interrupts. Combine this complexity with thousands of threads using
tens
of thousands of wait objects in much more complex ways than sleep
(like
WFMO and Semaphores, GQCS & IOCP, or Timer Queues) and it is easy to
see
why a fixed timer interrupt interval would be the implementation of
choice.








.

Relevant Pages

  • Re: fixed time slices?
    ... to WFSO using an event that gets signaled just *after* WFSO ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, it ... Scheduler "ticks" only ... systems may also provide high-resolition interval timer, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: fixed time slices?
    ... high resolution timer(timeBeginPeriod), check ... to WFSO using an event that gets signaled just *after* WFSO ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler planed ...
    (microsoft.public.win32.programmer.kernel)
  • Re: fixed time slices?
    ... Sleep(1) will sleep at least one hardware timer tick, ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler planed ...
    (microsoft.public.win32.programmer.kernel)
  • Re: fixed time slices?
    ... This hasn't anything to do with hardware's timer resolution ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler planed ...
    (microsoft.public.win32.programmer.kernel)
  • summary (Re: [patch] prefer TSC over PM Timer)
    ... and attempted to summarize the ... if timer_pm is fixed to read the PM timer only once on non-broken systems ... until/unless C3 and deeper resync tsc then it's best not to default to tsc ... can't be shared with scheduler if we add variable scheduler ticks ...
    (Linux-Kernel)