Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)

On Monday, January 19th, 2026 at 9:17 AM, Olivier Certner <olce@freebsd.org> wrote:
> > Someone in the thread said the interactivity score is "bogus": although I wouldn't go that far, interactivity score sacrifices fairness and we definitely need patches to handle edge cases (similar to what CFS experienced on linux side).
> 
> 
> Not sure what you had in mind exactly but, as is, this statement about CFS makes no sense. CFS works by maintaining an execution time which it uses to ensure fairness as it allows to check whether some thread has been less executed than another. There's no interactivity score at all in CFS, so there certainly aren't any patches to fix problems with that.

Sorry, I meant "handle edge cases" because CFS was TOO fair. Now they partially solved the problem with EEVDF.

> Now, turning to ULE's well-known main problems (which I've analyzed not only with merely running examples, but actually hacking the scheduler and support programs that produce statistics):
> 1. The effect of nice values is too low, to the point of insignificance. As a striking example, a thread with an offset nice value of -20 competing with one with a value of 20 will get the CPU only 66% of the time. A nice value of 0 against 20 only gives a +4% CPU time advantage compared to total fairness (nice values been equal). See https://reviews.freebsd.org/D46566 for details.

Yes, that's what I meant for "polluting" nice values. I didn't mean nothing should override nice (no sane scheduler does that these days anyways), but ULE should respect nice more. I'll take a look at the patch.

> 2. There is a fairness issue for threads in-between interactive ones and CPU hogs, i.e., doing a non-trivial amount of computation so that they are not considered interactive, but at the same which frequently do not use the full quantum. In this situation, with the current code, the amount of not-used quantum is simply lost.
> 
> There were earlier attempts to fix point 2 but they were not satisfactory enough. I have been having a solution for it, which I ran by Jeff who agreed it was worth testing. I also have a solution for point 1 as well which is relatively simple and most probably will turn out to be sufficient to give much more weight to nice values, and change the scale to be an exponential one (so that the effect of a shift in nice values is, from a relative point of view, the same whatever your current nice value is). In terms of coding, each of them shouldn't take me more than a week or two. What really takes time with scheduling matters is rarely coding per se, but, beyond high-level analysis and design (already mostly done in these cases), tests and actual measurements, as well as comparing the behavior of a variety of workloads before and after the changes.

Having exponential nice conversion table like BFS/CFS/EEVDF would be great.

> 
> These have been in my TODO list for a relatively long time now, without ever reaching the top for various reasons. They still probably won't in the immediate (as I'm mostly working on Power matters at the moment) but since there seems to be some interest, hopefully I'll be doing them in a month or two. Once these problems are fixed, it's likely that, experiments confirming, there won't be any more reason to keep 4BSD around. One of my personal goals is to deprecate 4BSD in 16 if possible, as it is more and more irrelevant on modern machines and seems too lightly tested.

I think I read about ULE being too reluctant on moving tasks between cores (or higher topology level). Is that problem solved?

Anyways, thank you for correcting my misunderstanding on ULE, I was too pessimistic on that scheduler. If possible, could you add me to subscribers to patches for issue 1 and 2 in future?

Regards,
Minsoo