Date: Mon, 27 Mar 2023 22:23:42 UTC
Quoting Mateusz Guzik <firstname.lastname@example.org>: >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.