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

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

[Con Kolivas]

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.

Patchlist:
Add -ck1 version.
Make nohz_full not be picked up as a default config option and add
recommendation to help.
Set default Hz to 100 in combination with MuQSS and -ck patches.
Make hrtimer granularity and minimum hrtimeout configurable in sysctl.
Set default granularity to 100us and min timeout to 500us.
Don't use hrtimer overlay when pm_freezing since some drivers still
don't correctly use freezable timeouts.
Replace all calls to schedule_timeout_uninterruptible to use
schedule_msec_hrtimeout_uninterruptible.
Replace all calls to schedule_timeout_interruptible to use
schedule_msec_hrtimeout_interruptible.
Convert msleep to use hrtimers when active.
Convert all low value schedule_timeouts to their hrtimeout equivalents.
Create highres timeout variants of schedule_timeout functions.
Make preemptible kernel default.
MultiQueue Skiplist Scheduler v0.31.

The patches are kept modular for easy porting to each successive linux
kernel version.
Out of deference to LKML's signal to noise ratio, please just reply to
me without CC'ing the mailing list for any discussion/issues.

Enjoy!
お楽しみください
-ck

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

[Jonathan Corbet]

Con Kolivas <con@kolivas.org> writes:

> 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.

I'm genuinely curious: have you considered moving this work to
sched_ext?  That would instantly make it much more widely available for
people to try out and actually use.

Thanks,

jon

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

[Con Kolivas]

On Tue, 18 Aug 2026 at 00:33, Jonathan Corbet <corbet@lwn.net> wrote:
>
> Con Kolivas <con@kolivas.org> writes:
>
> > 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.
>
> I'm genuinely curious: have you considered moving this work to
> sched_ext?  That would instantly make it much more widely available for
> people to try out and actually use.

Considered yes. It would work for the scheduling policy but there's no
way to extend it to runqueue sharing which provides half the benefit.

Thanks,
Con
>
> Thanks,
>
> jon

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

[Steven Rostedt]

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,

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). 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.

I recently received a grant on using Anthropic's max claude for 6 months
(pretty much unlimited tokens) to do this.

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.

-- Steve

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

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

[Con Kolivas]

On Sun, 23 Aug 2026 at 00:21, Steven Rostedt <rostedt@goodmis.org> 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

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@goodmis.org> 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

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

[Steven Rostedt]

On Sun, 23 Aug 2026 12:08:19 +1000
Con Kolivas <con@kolivas.org> wrote:

> 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.

Yeah, the main reason I call it a "governor" and not "plugable" is
because I wanted to stress that it's not for any scheduler. It is for
an environment. Similar to the power management governors. Saying
"plugable" gives a "plug and play" feel that I wanted to avoid. Ingo's
complaint back then was that we would have hundreds of schedulers. Now
with sched_ext, that's exactly what we have. Thus, the governor was an
idea to bring back collaboration between folks that work in the same
environment.

> 
> 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.

I'm not sure you are aware that the Linux kernel today has something
called a "static_call"[1]. It's a direct function call that can be
switched at runtime with run-time code modification. It is something
that I was planning on using.

> 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.

For my idea, I would have the governors only affect SCHED_OTHER and
SCHED_IDLE. The RT and DL schedulers would not be affected. But having
the governor take over the idle and other tasks, it would have more
control of what it could do.

> 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.

I believe mainline is going in this direction too.

> 
> 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.

Again, indirection is solved by the static calls. When spectre and
meltdown mitigations were introduced into the kernel, indirect calls
took a hugh hit. Tracepoints used them quite extensively and it slowed
down hackbench with the sched_switch tracepoint active by 10%!

I started working on a way to replace indirect calls with a direct call
that could be modified. Then Josh Poimbeouf took over and Linus didn't
like the implementation.Finally, Peter Zijlstra got it into the kernel.

They are expensive to change, but for things that do not change often
(like enabling a tracepoint, picking a KVM implementation, or picking a
specific scheduler governor) it is really useful. The hackbench
slowdown disappeared and tracepoints are actually even faster than what
they were with the indirect calls.

-- Steve

[1] https://lwn.net/Articles/815908/

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

[Con Kolivas]

On Mon, 24 Aug 2026 at 00:28, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Sun, 23 Aug 2026 12:08:19 +1000
> Con Kolivas <con@kolivas.org> wrote:
>
> > 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.
>
> Yeah, the main reason I call it a "governor" and not "plugable" is
> because I wanted to stress that it's not for any scheduler. It is for
> an environment. Similar to the power management governors. Saying
> "plugable" gives a "plug and play" feel that I wanted to avoid. Ingo's
> complaint back then was that we would have hundreds of schedulers. Now
> with sched_ext, that's exactly what we have. Thus, the governor was an
> idea to bring back collaboration between folks that work in the same
> environment.

Fair enough.
>
> >
> > 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.
>
> I'm not sure you are aware that the Linux kernel today has something
> called a "static_call"[1]. It's a direct function call that can be
> switched at runtime with run-time code modification. It is something
> that I was planning on using.

No, I was not aware, that takes the worst aspect off the table.

>
> > 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.
>
> For my idea, I would have the governors only affect SCHED_OTHER and
> SCHED_IDLE. The RT and DL schedulers would not be affected. But having
> the governor take over the idle and other tasks, it would have more
> control of what it could do.

Sounds good. MuQSS' multiple runqueues would be better without having
to handle RT tasks as well - there's a corner case where checking
another runqueue for its best task won't find the best SCHED_OTHER
task if there's an RT task ahead of it (though in the desktop it would
probably be one runqueue.)
Switching to a different number of runqueues on the fly would require
some special handling, something like the CPU hotplug paths used for
suspend/resume.

>
> > 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.
>
> I believe mainline is going in this direction too.

Sounds good.
>
> >
> > 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.
>
> Again, indirection is solved by the static calls. When spectre and
> meltdown mitigations were introduced into the kernel, indirect calls
> took a hugh hit. Tracepoints used them quite extensively and it slowed
> down hackbench with the sched_switch tracepoint active by 10%!
>
> I started working on a way to replace indirect calls with a direct call
> that could be modified. Then Josh Poimbeouf took over and Linus didn't
> like the implementation.Finally, Peter Zijlstra got it into the kernel.
>
> They are expensive to change, but for things that do not change often
> (like enabling a tracepoint, picking a KVM implementation, or picking a
> specific scheduler governor) it is really useful. The hackbench
> slowdown disappeared and tracepoints are actually even faster than what
> they were with the indirect calls.

Very good. Looking forward to seeing your progress.
I've split out the muqss patch into two separate patches on a new git
branch, leaving the IO time code as a separate patch, making it
possible to concentrate purely on the scheduler components.
https://github.com/ckolivas/linux/tree/7.2-muqss

>
> -- Steve
>
> [1] https://lwn.net/Articles/815908/

Thanks,
-ck