Re: [ANNOUNCE] linux-7.2-ck1, MuQSS CPU scheduler for linux-7.2

[Con Kolivas]

[trimmed to relevant governor discussion]

> On Sun, 23 Aug 2026 at 00:21, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>> But it did get me thinking. I found that trying to have
> > one scheduler to handle multiple environments wasn't optimal. I would like to
> > have different schedulers for different environments (one for phones, one for
> > desktops, one for servers). I would use your MuQSS scheduler as the desktop
> > governor.
>
> Interesting, that is why I tried the pluggable approach indeed.
>
> MuQSS was my attempt to address the fact the earlier BFS design was
> constrained to only being useful in desktop/mobile environments and
> was configurable for different workloads - but it received almost no
> attention outside desktop use as that was obviously what I initially
> developed it for. My own limited benchmarks showed it performed very
> well there anyway. However the requirements for all the extra features
> bolted onto the basic scheduler with cgroups etc. made it far too big
> for one person to develop. In the end as you know I didn't even have
> time to maintain even the basic functionality.
>
> I'm curious to see just how your scheduler governors differ in
> practice from a pluggable scheduler - it seems on the surface to do
> exactly the same thing by proxy anyway (I have yet to watch your
> presentation, I will check it out soon.) sched_ext as I said in
> response to Corbet is not extensible enough for some of MuQSS'
> architecture.
> >
> > I recently received a grant on using Anthropic's max claude for 6 months
> > (pretty much unlimited tokens) to do this.

> > -- Steve
> >

Hi again Steve et. al

> > [1] https://lwn.net/Articles/1020596/
> > [2] https://docs.google.com/presentation/d/1dtm0AiiTI30gTFeKj95vmSyirYmk5_QiR_lh17l_Moo/edit?usp=sharing

I'm now caught up with your presentation as presented in the youtube
video linked in the lwn article. Thanks, very informative and
thoughtful. I was unable to access the google doc but have requested
read access - though I believe it was all presented on the video.

Your governor idea is not as dissimilar to plugsched as may appear on
the surface. Plugsched built in all the schedulers into the kernel and
allowed you to boot the scheduler of your choice at boot time; it was
not to just build one scheduler into the kernel. Making it switch on
the fly was a pipe-dream goal but since it got shot down in
spectacular fashion I did not pursue it further. Its code is also so
outdated that literally nothing is of relevance in the current kernel
tree.

If you do pursue the governor idea there are a few things worth noting
about how high up and broad the hooks need to be.
One overhead problem with plugsched was it added a layer of
indirection to every single scheduler function call that was shared
between different schedulers. The cost of this may be considered
either trivially irrelevant or not remotely worth it depending on your
viewpoint. A the time I wrote plugsched, Itanic[sic] was still an
active architecture and the indirection was considered a huge
downside.
There are four broad aspects to achieving low latency with muqss which
all need to be adopted to reproduce its behaviour, in order of
decreasing importance.
1. Policy - the simple ordering aspect based on deadline, timeslice
interval etc. based on a shared monotonically increasing nanosecond
time counter.
2. Shared access to a global queue - BFS did this by having only one
queue. MuQSS was created as a way to address scalability concerns by
reintroducing separate runqueues. It became clear very quickly that
policy alone did not reproduce the behaviour of BFS and that's where
the idea for having shared runqueues came about. The more the
runqueues were shared, the closer the latency approximated BFS'. The
default configuration chooses MC - Multicore. For virtually all
desktops and mobile devices that means they all end up with one
runqueue anyway. It is pre-configurable in kconfig, but also boot-time
selectable.
3. Busy and idle load balancing. In MuQSS' case the busy balancing
happens by proxy through the next task selection, but idle balancing
is handled separately. Mainline handles both of these separately from
policy.
4. Highres timer based scheduling to effect the nanosecond timers.
This is to disentangle the scheduler's latency dependency on the
chosen jiffy Hz which ties all other subsystem components to that
resolution and/or overhead.

None of these are insurmountable endpoints with enough LLM tokens, but
I suspect there will at least be one/some indirection somewhere in the
implementation.

Thanks,
-ck