Re: Periodic rant about SCHED_ULE

From: Alexander Leidinger <>
Date: Thu, 23 Mar 2023 07:57:45 UTC
Quoting Mateusz Guzik <> (from Wed, 22 Mar 2023  
20:23:42 +0100):

> sched_4bsd *round robins* all workers across all CPUs, which comes at
> a performance *hit* compared to ule if number of workers is <= CPU
> count -- here ule maintains affinity, avoiding cache busting. If you
> slap in $cpu_count + 1 workers, 4bsd keeps the round robin equally
> penalizing everyone, while ule mostly penalizes a select victim. By
> the end of it, you get lower total cpu time spent, but higher total
> real time. See below for an example.
> Two massive problems with 4bsd, apart from mandatory round robin which
> also happens to help by accident:
> 1. it has one *global* lock, meaning the scheduler itself just does
> not scale and this is visible at modest contemporary scales
> 2. it does not understand topology -- no accounting done for ht nor
> numa, but i concede the latter wont be a factor for most people
> That said, ULE definitely has performance bugs which need to be fixed.
> At least for the case below, 4BSD just "lucked" into sucking less
> simply because it is so primitive.

IIRC ULE also has a semantic difference compared with 4BSD in terms of  
handling of the "idle" (and realtime) priority. What I remember (it's  
been a while since ULE was introduced) is, that with 4BSD the  
idprio(1) case could result in such processes getting no CPU time,  
whereas with ULE it is quaranteed that such processes will get "some"  
(no idea what a more specific description of "some" would be) CPU  
time. BTW: someone may want to review the BUGS part of idprio(1) if  
the part about "preempted" is still correct.

I remember there was a lengthy discussion about the handing of process  
priority back then, but a quick googling didn't seems to have had the  
right keywords to find it. What I got was this:

Original ULE design/scientific paper:

Laymans-terms description:

ULE 2.0:

Discussion about ULE/prio/sche_preempt_threads sysctl:


-- PGP 0x8F31830F9F2772BF  : PGP 0x8F31830F9F2772BF