"André Braga" <meianoite@xxxxxxxxx> wrote:
> A fair, priority-based scheduler would schedule a thread with
> B_NORMAL_PRIORITY half as many times as another thread with
> B_URGENT_DISPLAY_PRIORITY, because the ratios among their numeric
> priorities is 1:2. We know pretty well that those are *not* the
> semantics we desire when we spawn threads using those priorities.
So why are you doing it this way, then? :-))
> So our options are to go the Linux route and base the fairness on CPU
> usage (and there are signs that this _doesn't_work_well_); try and
> manage to implement branding (a.k.a. subsystem-based priority
> inheritance) in order to boost threads that are supposed to be very
> responsive; or give up on the goal of having a fair scheduler and go
> back to using a static, sorted-by-priority-based scheduler like the
> one in BeOS.
We have to keep track of the CPU usage of every thread anyway, so that
at least wouldn't cause much additional trouble. Have you thought about
using the thread priority as well as the CPU usage to compute the
ratios?
For example, you could do something like ("priorityWeight" * priority /
average CPU usage) and would therefore automatically boost high
priority threads that don't use their full quantum over those that do.
The "priorityWeight" would just be some arbitrarily chosen value that
defines how important the priority is in comparison with the CPU usage.
Bye,
Axel.