The -ck patchset aims to improve desktop/mobile device responsiveness, interactivity, and gaming, mostly by replacing the CPU scheduler en-bloc with my MultiQueue Skiplist Scheduler.
New feature: I/O aware CPU scheduling accounts read and write time to the calling task. Also accounts work done in kthreads on behalf of a calling task.
Numerous bugfixes for suspend/hibernate/shutdown, hotplug, and minor tweaks.
Dropped irqthreads as it was a net negative for workstations.
Patch list:
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.
I got the message there were enough people still following this blog so I will not be dropping it.
Enjoy!
お楽しみください
---
-ck
hi,
ReplyDeleteI have installed MuQSS 0.3 ck2 for 7.1 and it has been smooth sailing, however 0.31 ck1 for 7.2 is not.
I found a simple way to reproduce the issue, run ```stress -c $(nproc)``` and move window around in KDE, results are as follows: mainline - a bit stutter, 7.1-ck2 - smooth af, 7.2-ck1 - way more stutter than mainline.
P.S. if you prefer getting issues in github, please say so
BR, Eduards
Interesting! We can discuss it here if you like. There was a 7.1-ck3 tagged as well, but not announced. Can you try that as well?
ReplyDeleteIf you want to check other commits if that still stutters, the next points on the 7.1-ck branch to check are ccdfe6e5da46e9d10666d8e8b0af27de53ea0724 and then aa930051bb9cf8d1d927e38b53c2f88cda2e317a
ReplyDeleteThanks.
Alright, so I tried 7.1-ck3 as well, and it stutters just the same. But the truly bizarre thing is that even 7.1-ck2 started stuttering after a fresh reinstall and reboot.
ReplyDeleteI can only seem to reproduce this on my Dell 11th gen laptop with Intel integrated graphics; there are absolutely no symptoms on my Ryzen desktop with a discrete GPU. Maybe the laptop is just doing typical laptop things based on system load, temperature, or the alignment of the stars :)
Since there is no concrete evidence or a repeatable scenario after all this testing, let's just leave it be for now.
If this issue pops up again or I will get to smth reproducible, I'll let you know.
BR, Eduards
That's okay, thanks very much for testing. Keep me informed!
ReplyDeleteBuild failure on 7.2-ck1 with CONFIG_PSI=y enabled (e.g. Arch's stock kernel config). Compiling kernel/sched/build_muqss.c fails with:
ReplyDeletekernel/sched/psi.c: In function 'psi_account_irqtime':
kernel/sched/psi.c:1025:33: error: 'struct rq' has no member named 'psi_irq_time'; did you mean 'prev_irq_time'?
Cause: build_muqss.c does #include "psi.c" under #ifdef CONFIG_PSI, pulling in vanilla psi.c unmodified. Vanilla psi.c references rq->psi_irq_time (added by the upstream PSI-IRQ-tracking commit from 2022). The -ck patch to struct rq doesn't declare that field — it only has MuQSS's own long-standing prev_irq_time field, used separately in MuQSS's own irq-time accounting. The two were never reconciled, so any build with CONFIG_PSI=y fails.
Reproduced cleanly against a stock kernel.org linux-7.2 tarball + the v7.2-ck1 diff (torvalds:v7.2...ckolivas:v7.2-ck1), confirmed via a dry-run patch apply (applies clean, no rejects) followed by a real build — fails at the same spot every time, on real hardware, not an emulation artifact. Likely why it hasn't surfaced before: most configs (including whatever you test with, presumably) don't have CONFIG_PSI enabled — it defaults off in vanilla Kconfig (no default line), but Arch's stock desktop config turns it on for systemd/cgroups-v2 pressure metrics.
Can you post your .config somewhere, like github issues, as I can't reproduce it here. Mine is built with CONFIG_PSY=y.
DeleteActually never mind, reproduced by finding the stock arch kernel config. Pushing fix to 7.2-ck branch, thanks!
DeleteBased on the official kernel documentation, the difference between NO_HZ_IDLE and NO_HZ_FULL looks a bit undeterministic to me.
ReplyDeleteThere is this specific commit and its message https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=176b8906c399a170886ea4bad5b24763c6713d61 to distros which basically states that NO_HZ_FULL introduces no overhead compared to NO_HZ_IDLE if the nohz_full parameter is not used.
This gives users the flexibility to take advantage of NO_HZ_FULL only when they actually need it.
From that perspective, there seems to be no downside to enabling NO_HZ_FULL by default unless the boot parameter is passed.
However, you recommend enabling NO_HZ_IDLE specifically and discourage using NO_HZ_FULL. Is there a hidden catch I'm missing as to why NO_HZ_IDLE is still preferred?
Ticks are used as a balancing hint in muqss and running no hz full loses that (admittedly extremely small) benefit. I'll look at removing that tick usage in future.
ReplyDelete