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

On Sun, 23 Aug 2026 at 00:21, Steven Rostedt <[email protected]> wrote:
>
> On Mon, Aug 17, 2026 at 12:32:43PM +1000, Con Kolivas wrote:
> > Announcing the return of the first stable version of my out-of-tree
> > patchset - not for mainline inclusion consideration.
> >
> > Tag:
> > https://github.com/ckolivas/linux/releases/tag/v7.2-ck1
> > Tree:
> > https://github.com/ckolivas/linux/tree/7.2-ck
> >
> > The -ck patchset aims to improve desktop/mobile device responsiveness,
> > interactivity, and gaming, mostly by replacing the CPU scheduler
> > en-bloc with my EEVDF, configurable runqueue sharing, MultiQueue
> > Skiplist Scheduler.
> >
> > It's been 10 years since I originally abandoned the patchset for time
> > reasons, but LLMs have made merging and development infinitely easier.
> >
> > Changes since the last publicly announced release are features I
> > planned years ago and never implemented that are new:
> > I/O aware CPU scheduling which accounts reads and writes to the calling task.
> > Kthread work on behalf of a calling task is accounted back to that task.
> > P/E core aware load balancing.
> > Skiplist structure size minimisation & micro-optimisations.
> > The mother of all resyncs to bring it up to 7.2.
> > Numerous bugfixes.
> >
> > Note: Scheduler CGROUPs remain no-op stubs as they are largely unused
> > in the target environments and would require massive amounts of code
> > to support.
> >
>
> Hi Con,

Hi Steve.
>
> Thank you for doing this. I'm actually trying to implement "Scheduler
> Governors"[1][2]. Back in 2023 when I was working on the Google ChromeOS team,
> we were looking for ways to improve our desktop performance. We had several
> benchmarks that we used. One was to run Google Meet with 16 users while typing
> in a Google Doc. This was fully automated (the test would simulate active
> users). We measured mouse jank and latency (key press, how long the screen
> would react after the mouse would move over a window, etc). We tested out your
> last MuQSS scheduler that you posted. It did extremely well. So much so, the
> tester wanted to push it upstream (I had to tell him about the history and
> that wasn't possible).

I was not aware of this work, thanks for pointing it out - I had not
been monitoring the linux kernel landscape for quite some time. It's
nice to see independent benchmarks verifying its validity.

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.

Fun project, go for it. Anthropic ignored me so I paid out of pocket
for what little access I did get. MuQSS is pretty stable in design now
after initial churn to properly sync up with mainline, and I've tried
to keep the patch monolithic in the -ck patchset.
>
> Peter Zijlstra hates this idea, but I want to do this and see if it is indeed
> an improvement. If anything, I'm hoping to improve the scheduler and perhaps
> with enough evidence it may be something to consider implementing upstream.

I don't know how to feel about this idea. Having a few hours
intermittently every few weeks or months only to dedicate to linux
kernel development is why I got out of it in the first place. As the
author, attempting to push it upstream would change the dynamic
dramatically. It would be presumptuous to think I could "fire and
forget" and not be available.
>
> -- Steve
>
> [1] https://lwn.net/Articles/1020596/
> [2] https://docs.google.com/presentation/d/1dtm0AiiTI30gTFeKj95vmSyirYmk5_QiR_lh17l_Moo/edit?usp=sharing

Thanks,
-ck