Re: Periodic rant about SCHED_ULE

Quoting Mateusz Guzik <mjguzik@gmail.com>:

>When deciding what to run, 4BSD uses runq_choose which iterates all
>queues from the beginning. This means threads of lower priority keep
>executing before the rest. In particular cpu hog lands with a high
>priority, looking worse than make -j 8 buildkernel and only running
>when there is nothing else ready to get the cpu. While this may sound
>decent, it is bad -- in principle a steady stream of lower priority
>threads can starve the hogs indefinitely.

Ideally, while starving, the priority of that hog should occasionally
get re-calculated, until it is low enough to run it again. Not sure if
that actually happens.

>The problem was recognized when writing ULE, but improperly fixed --
>it ends up distributing all threads within given priority range across
>the queues and then performing a lookup in a given queue. Here the

As I did understand it, the ULE run-queue is circular and works like
a revolver barrel. So yes, once in a while everybody gets a shot.

>problem is that while technically everyone does get a chance to run,
>the threads not using full slices are hosed for the time period as
>they wait for the hog *a lot*.

Yes, exactly. The hog stays at the pole position until they use up
their quantum.