Date: Tue, 28 Mar 2023 00:23:42 +0200 From: Peter <pmc@citylink.dinoex.sub.org> To: freebsd-hackers@freebsd.org Cc: Mateusz Guzik <mjguzik@gmail.com>, Matthias Andree <mandree@freebsd.org> Subject: Re: Periodic rant about SCHED_ULE Message-ID: <ZCIXbsNOBOaMRPhx@disp.intra.daemon.contact> In-Reply-To: <CAGudoHFPqz_LtsVNnz4P2gyKXz5Z8hU%2Bv6QYGizm4%2BDtZRn8Yg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZCIXbsNOBOaMRPhx>