Re: Call for Foundation-supported Project Ideas

From: Stefan Esser <se_at_freebsd.org>
Date: Tue, 30 Nov 2021 11:53:20 UTC
Am 23.11.21 um 23:41 schrieb Joseph Mingrone:
> Hello FreeBSD community,
> 
> The Foundation is seeking suggestions for new projects to support.  What
> gaps in the Project are not being addressed by the broader community?

The "new" ULE scheduler has a number of well-known issues, which leads
to the "old" BSD scheduler giving better performance on many systems
and loads, but is based on concepts that made sense in pre-SMP times.

ULE suffers from pathological behavior in many scenarios, and it does
not know how to best deal with simultaneous multi-threading, big/little
architectures, or the effects of virtualization.

ULE does not care for the "niceness" of a process and lets nice -19
processes run with hardly any reduction of the share of CPU cycles
granted compared to competing nice 0 processes, for example.

Virtualization gives a number of additional requirements and restrictions
in both the host and client. Schedulers in other operating systems have
been modified to reduce the risk of side-channel attacks by running only
processes for one user at a time on the virtual processors of an SMT core.

Within a virtual machine, the real topology of the underlying hardware
may be hidden and scheduling effects by the VM host may need to be taken
into consideration (e.g. clock variations and "time jumps"). There is
a connection to bhyve, at least (perhaps also to other virtualization
platforms) that has to be taken into account.

Another aspect is optimization for performance vs. optimization for
low power use, which both require a specific scheduling strategy on
complex CPU topologies.

IMHO, a scheduler design that is based on experiences gained by other
projects and our knowledge of deficiencies of the currently available
schedulers in FreeBSD under specific loads could be a huge win for the
project.

This would be a long-term project, and I do not see any developer
currently working on designing or implementing a new scheduler.

There have been minor changes to SCHED_ULE, recently, but I'd think
that a completely new design will be required, based on knowledge
gained in the last 1 or 2 decades and able to deal with architectural
changes that have occurred in that time frame.

Regards, STefan