[haiku-commits] Re: BRANCH pdziepak-github.scheduler [3ee37b3] in src/system/kernel: scheduler locks
- From: Pawel Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 29 Nov 2013 18:35:00 +0100
2013/11/29 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
>> On November 29, 2013 at 5:30 AM "pdziepak-github.scheduler"
>> <community@xxxxxxxxxxxx> wrote:
>> + bigtime_t maximum_latency;
>
> Out of curiosity: does it make sense to have a maximum latency that is valid
> for
> all thread priorities? (I assume that this is not true for real time threads?)
> Wouldn't it make more sense to only apply that maximum to non CPU bound
> threads
> with a certain priority (say 5 or 10)?
> Or am I misunderstanding this thing?
The main reason for introducing this maximum_latency value is to
reduce time a thread has to wait before it is scheduled again where
there is a big number of threads ready for execution. Obviously, for
CPU bounds threads that do nothing but computations it doesn't really
matter, but such threads are rare. In most cases the thread becomes
CPU bound since it is producing (e.g. renderers like GLTeapot),
consuming or both large amount of data. In such cases, when the work
the thread is doing is immediately visible, extended waits are not
acceptable, the threads should appear to run smoothly regardless of
the system load.
This also applies in some extent to the threads that are not CPU
bound. When there is a big number of high priority threads that
consume a significant amount of their time slice (but not enough to be
recognized as CPU bound) we would like to make sure all of them get a
chance to run often enough, so that their respective time slices are
shortened.
Paweł
Other related posts:
