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

On Mon, Jan 19, 2026 at 02:59:10PM +0000, Minsoo Choo wrote:
> On Monday, January 19th, 2026 at 9:30 AM, George Mitchell <george+freebsd@m5p.com> wrote:
> 
> > 
> > 
> > On 1/19/26 09:17, Olivier Certner wrote:
> > 
> > > Hi,
> > > 
> > > This is a mail intended to spread the news. I must also admit to getting a bit tired to see the same misconceptions and falsities on ULE, and even on schedulers in general, repeated over long periods of time by several people.
> > > [...]
> > > 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.
> > 
> > > [...]
> > 
> > Thanks for this explanation and progress report.
> > 
> > Rather than deprecating 4BSD, has anyone thought about making it a load
> > time tunable, perhaps even a loadable kernel module? Or, in the world
> > of packages for base, having the scheduler be its own package?
> > Especially if someone wants to write yet another scheduler? -- George
> 
> That would be something similar to sched-ext on Linux except it is kernel module not eBPF. It's worth considering but cleaning up scheduler interface should be done first.
> 

It is not much depends on the scheduler interface, and in fact
making the 4bsd and ule modules is almost trivial. Almost because of
cpu_switch.S cpu_switch() code, which must not wait for blocked thread
lock to unblock for 4bsd, on all architectures.

The hard part was make the struct thread scheduler addend scheduler-agnostic,
but this is done.  See how the allocations from the thread_zone are sized,
and thread0_storage is set.

There are also two other places in x86/ which depends on ule, one adding
full seqcst fence, which can be done unconditionally in cpu_machdep.c,
and another in local_apic() which might require adding one more sched_XXX()
function.