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