Linux-7.2.7-ck1

I've tagged v7.2.7-ck1 with a couple of fixes for muqss and the I/O aware scheduling, and synced it up with the latest stable version.

https://github.com/ckolivas/linux/releases/tag/v7.2.7-ck1

MuQSS and meaningful benchmarks

  One of the most painful aspects of developing MuQSS for desktop responsiveness and interactivity has always been that all regular benchmarks are measuring things that are completely orthogonal to its target goals. Apart from testing if and how much they affect regular benchmark results, they do nothing for testing the target effects.

During my extended downtime away from linux kernel development I completely missed that Steven Rostedt had conducted benchmarks on MuQSS for the low power Google Chromebook looking for exactly that in 2023. He kindly alerted me to this work and an LWN.net article where it was discussed in 2025. With his permission I have created a copy of his presentation:

 2025 OSM Scheduler Governors Presentation

This is a summary of the relevant original benchmark results from 2023 in these graphs. (Lower is better.)

 

 

 

 LWN article:

https://lwn.net/Articles/1020596/ 

 And the full video of his presentation on youtube. The full explanation of these results is in the video from about 12:30:

 https://www.youtube.com/watch?v=VIyfhuEVmeQ 

 He has opened an interesting discussion about resuscitating the idea behind his scheduler governors you can follow here:

 https://lkml.org/lkml/2026/8/22/412

  -ck

Linux-7.1.9-ck3

 Here's a resync with the latest stable linux-7.1.9 for those having issues with, or not wishing to try 7.2. Same patches as 7.2-ck1

https://github.com/ckolivas/linux/releases/tag/v7.1.9-ck3 

I/O aware CPU scheduling support discussion

 You may have seen the new I/O aware scheduling support mentioned in the announce posts or as an option when configuring your kernel. This was my attempt to tackle a long-standing problem with CPU scheduling whereby a task does some I/O work - read or write, and then it returns and gets high priority treatment since it's seen as a sleep. This leads to heavy I/O tasks getting preferential treatment when they could be bogging down the system for both CPU and I/O. Tackling this required a fairly invasive patch that incurs overhead that would be considered problematic if looking at it purely from the I/O performance perspective. That is why I made it configurable at kernel config, but defaulting to on since muqss users are rarely interested in I/O benchmarks. The effect on performance is quite negligible.

 However it unfortunately only realistically helps for the lesser half of the problem - reads. Writes are much slower and also tend to bog the system down much more. Whilst the code does try to attribute write time to the calling task, the nature of the linux writing subsystem means it all happens way too late to actually help. Writes are handed off the the virtual memory subsystem as "dirty" ram and then subsequently written out often many seconds later. By that time the CPU scheduling of the calling task has long since ended and the process may not even exist anymore. Nonetheless since I was implementing it, I included this path in the unlikely even there was a sustained write streaming task for it to be captured.

The following sysctls may theoretically help at capturing the writes better, but I've been unable to demonstrate a significant improvement, and they may have undesirable effects so I have not included them in -ck:

echo 0 > /proc/sys/vm/dirty_expire_centisecs

echo 1 > /proc/sys/vm/dirty_writeback_centisecs 

I'm curious to see if anyone has a workload they find this does help with, as I could gate these as default settings behind the I/O aware config option as defaults.

 

If you want to see the effect of having every task (effectively) wait for its writes before moving on, try setting this sysctl as root:

echo 0 > /proc/sys/vm/dirty_ratio

 Write performance crashes to a fraction of normal, and even a kernel compile takes more than twice as long. The normal value is 20 for when you want to restore it. Setting it to 1 is no better than 20 for any meaningful effect, as it does nothing to actually help capture write times and attribute them to the calling task.

-ck