Re: fixed time slices?


"Jan Bruns" <testzugang_janbruns@xxxxxxxx> wrote in message
news:468134af$0$20292$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"m" <m@xxx>:
"Jan Bruns":

But the scheduler would also have the chance to let the hardware
generate
a timer-IRQ within wahtevr delay is desired. So it could put the CPU on
a ready low-priority thread for as long as a higher priority thread is
known to be unrunnable.

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.

Shouldn't this be possible for any other event, too?
An event can only become signaled if the system sets it.
So the system would be able to directly call the scheduler,
whenever it signals an event. The scheduler would in turn
update it's timer, and decide wether to continue the thread
that raised the signalling, or to switch to a higher priority
thread that is yet runnable.

Yes the system does call the scheduler when a sync API is called but in
complex cases the scheduler cannot behave omnipotently.



Consider a relativly simple case where three threads are involved A, B, & C
with priorities low, med, & high respectively. Threads B & C are waiting on
a mutex and thread A running on CPU 1 signals it. The scheduler then runs,
detects thread C as ready to run and switches CPU 1 to thread C. Even if
there is a CPU 2 for thread B to run on, which might be executing a thread D
with even lower priority, there is no way to execute thread B immediately
without somehow signalling CPU 2 and by the time you did that CPU 2 might be
executing a higher priority thread than B. CPU 2 might also be scheduling
threads and detect thread B before you could signal it or it might be halted
waiting for work to do. There is no way to tell; and even if your could,
the information could be out of data before you could act on it.



This scheduling is further complicated by APCs (kernel & user), thread ideal
processors, affinity masks and NUMA architectures.



The short answer is that while it may seem trivial to say that the scheduler
should do something, the best you can do in windows is to set your thread
priorities (carefully) and assume that the scheduler will schedule your
threads some time close to when you want them to run; and you can improve
the precision of scheduler, at some performance cost, by using APIs like
TimeBeginPeriod.


.

Relevant Pages

  • [RFC][PATCH] O(1) Entitlement Based Scheduler
    ... This patch is a modification of the Oscheduler that introduces ... _entitlement_ to CPU resources that is determined by the number of _shares_ ... This patch provides both soft and hard CPU usage rate caps per ... one getting the most can be given a better priority, ...
    (Linux-Kernel)
  • [patch] 2.6.21-rc4 nicksched v32
    ... Considering the recent attention on CPU schedulers, ... but it is yet another scheduler. ... struct pipe_inode_info; ... 'User priority' is the nice value converted to something we ...
    (Linux-Kernel)
  • [patch 1/] timers: tsc using for cpu scheduling
    ... uses jiffies_64 for process priority calculation instead of Time Stamp ... Clock (TSC). ... process which provoke to memory threshing and bad cpu and cash using has ... But for scheduler purposes the value of work ...
    (Linux-Kernel)
  • Re: Where is RLIMIT_RT_CPU?
    ... average) more CPU than they would get running at normal priority. ... most audio applications tend to only ... the higher priority one leaves enough cpu for the lower priority one. ... That solution doesn't need anything added into the scheduler. ...
    (Linux-Kernel)
  • [PATCH -v2 0/7] New RT Task Balancing -v2
    ... dirtying caches for large number of CPU boxes. ... That is to say that a high priority thread that is scheduled on a CPU ... Then it takes a time stamp and starts all the threads. ... Sometimes a lower priority task might wake up before a higher priority, ...
    (Linux-Kernel)