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

On Monday, January 19th, 2026 at 12:54 PM, Olivier Certner <olce@freebsd.org> wrote:

> 
> 
> > Please, do not deprecate 4BSD.
> 
> 
> 4BSD will be deprecated provided we can fix ULE's mentioned problems as expected, since, AFAIK, they are the only cases where 4BSD can fare better.
> 
> > Although it's been
> > a long time since I benchmarked 4BSD vs ULE with my
> > OpenMPI-based code, 4BSD handled the work load much
> > better than ULE. Yes, I made Jeff aware of the
> > situation.
> 
> 
> Did this notification produce any useful discussion, and even an analysis?
> 
> > It's unclear how you conclude that 4BSD is lightly
> > tested. Maybe 4BSD simply works and there's nothing
> > to report.
> 
> 
> Simple:
> - 4BSD has not been the default scheduler since more than 18 years, and the choice of scheduler must be done at kernel compilation time. That has reduced its exposure to those people that will install custom kernels with it explicitly re-enabled. I'm willing to bet this is a very small cohort. Feedbacks would of course be better.
> - During that course, some 4BSD bugs have persisted for years (such as incorrect %CPU reporting) and, AFAIK, almost nobody complained.
> So it seems unlikely we are in the "simply works and there's nothing to report" case.
> That said, I assume it still mostly works, and when doing runqueue changes took care to avoid disturbing its behavior (and, in one case, likely improved it). But I only test it very lightly.
> 
> Going forward, I'll send a call for testing once the mentioned problems are fixed. Then, re-testing your scenario would be helpful and the most constructive move. There's no point in keeping 4BSD if there's not a single scenario where it is clearly better.
> 
> --
> Olivier Certner

The existence of 4BSD ensures that we have scheduler-agnostic kernel code, but that's not valid anymore if we 1) introduce another scheduler (e.g. EEVDF) or 2) separate schedulers into kernel modules.