BMQ v5.4-r2 is released with the following changes
1. Change SCHED_BMQ Kconfig location. Now BMQ related Kconfig can be found under "Scheduler features"
2. Update recommend SCHED_TIMESLICE. 2ms is recommend for PREEMPT(Preemptible Kernel (Low-Latency Desktop)) system, 4ms for others.
3. Update yield_type documentation.
After weeks of experience, 2ms scheduler time slice is recommend for BMQ. The overhead introduced by double the time slice switches is so far acceptable.
Enjoy BMQ for your linux kernel, :)
Full kernel tree repository can be found at https://gitlab.com/alfredchen/linux-bmq
And all-in-one patch can be found at gitlab.
Bug report at https://gitlab.com/alfredchen/bmq/issues
Every time I try to apply a newer version of the patch in a build made with an older version, there are always several errors. If I apply to a "clean" build, everything works perfectly. The first problem is with the patch documentation that is not replaced. Then there are several other problems that I have no way to post them, because I already closed the terminal.
ReplyDeleteAlso, thanks again! :)
If you mean what i think you mean, ofc there will be errors, cos the all-in-one patch is not incremental, but a "clean" patch. You cannot have BMQ patched source of eg. 5.4.13 and THEN apply this patch.
DeleteYou could pull patches from Alfred's git tree and apply them 1 by 1 tho.
Sorry if i misunderstand you tho.
Exactly this! Thanks for explain. :)
Delete@Alfred:
ReplyDeleteThank you very much for continuously improving BMQ !
Although I ensured, the v5.4-r2 is applied correctly and the CONFIG_PREEMPT=y is set, CONFIG_SCHED_TIMESLICE=2 doesn't automatically gets set (from the previous default of 4).
Is this the intended behavior, thus meaning that I simply don't understand the mechanism within commit fcf7aea5 "bmq: Update recommend SCHED_TIMESLICE" ?
Thanks in advance for a short clarification,
Manuel
I think the default value is assigned when there is no value is set.
DeleteYeah. I considered posting about this yesterday, but decided since this patch is not providing a example config it was kinda beside the point.
DeleteSo, to recap: doing a "make oldconfig" will NOT change CONFIG_SCHED_TIMESLICE=2 if it is already set to 4.
However, if you take your .config file and delete the lines with CONFIG_SCHED_BMQ
CONFIG_SCHED_TIMESLICE, and THEN do a "make oldconfig", and if you answer "Y" to the question asked about BMQ, the default will then be 2 as long as you have PREEMPT set in the config.
I was actually investigating if it was possible to make this a hard requirement, but then i guess you would loose the ability to customize.. Cos you could "require" TIMESLICE to be set to 2 once you select PREEMPT by putting it there perhaps.
Anyway, yeah the answer is "if no value is set" it will be correct :)
@Alfred & @Sveinar:
DeleteThank you both for the quick and clear reply.
I've manually set CONFIG_SCHED_TIMESLICE=2 after reading the recommendation and recognizing the mismatch.
@Alfred:
Nevertheless, maybe it's worth to add this point "Please manually check and adjust the sched timeslice value in your kernel config" in the top introducing posting (?).
Thank you and best regards,
Manuel
Both original 4ms or current 2ms should work well with BMQ. It's just a recommend setting, not a MUST HAVE one. Users can try different setting based on their hardware and system usage. For example, for system with elder cpu, maybe 4ms is a better choice than 2ms for CONFIG_SCHED_TIMESLICE.
Delete@Alfred:
DeleteThank you for additionally pointing out this:
"For example, for system with elder cpu, maybe 4ms is a better choice than 2ms for CONFIG_SCHED_TIMESLICE."
Currently, running with 2ms for the first time, I experience video playback stutters, in circumstances where there were none before (e.g. with v5.4-r1 and earlier).
BTW, when experimenting with the CONFIG_SCHED_TIMESLICE value, am I right that it doesn't need to be power of 2 ?
Maybe it would be nice to have this TIMESLICE runtime configurable?
BR, Manuel
@Manuel
DeleteYou can experiment the time slice value and see if it is the cause of stutter on your system(old?), and report back.
CONFIG_SCHED_TIMESLICE doesn't need to be power of 2, just my programmer's habit. ;)
@Alfred:
DeleteThank you very much for your explanation !
Indeed, it's the same old HP Compaq 6730b Notebook, since years, with an old 1st gen "CPU0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (family: 0x6, model: 0x17, stepping: 0x6)" (from dmesg entry "smpboot:"). It's still sufficient for my needs.
Yeah, in fact I started testing CONFIG_SCHED_TIMESLICE=5 some hours before your reply. I can only report my subjective impression, comparing with the previous experience:
The now tested value of 5 looks like to be much better than 2 and even better than 4 (default upto v5.4-r1) on my system -- regarding both: throughput and interactivity. This setting of 5 produces far less stutters on here.
With my future kernel compilations I'd test increasing the value step-by-step and will report back. Maybe I can even catch a "break-even-pont", but it'll be a not really scientific result.
BR, Manuel
@Alfred:
DeleteI'm running CONFIG_SCHED_TIMESLICE=6 for over 31h now (with above mentioned system).
This looks like the most stutter-free setting for my system since months.
I haven't noticed any stutters nor other problems.
(This is still for a 5.4.15 kernel.)
Thank you for the hints and explanations regarding this setting,
maybe you can consider to make it either runtime- or boot-configurable,
BR,
Manuel
@Manuel
DeleteThanks for your reporting. Old cpu should use larger value than recommended. But I will still keep the recommended value for up-to-date CPUS, will consider make it a boot-time configurable parameter later.
@Alfred:
DeleteAnother day later my system (with CONFIG_SCHED_TIMESLICE=6) still looks stutter-free and well-balanced (2 hibernations).
Another observation: This setting also seems to have an effect on resuming from hibernation. In my case the system becomes responsive again much earlier than with settings of 2ms, 4ms or 5ms. This still depends on RAM & swap occupation, but the difference is countable in many saved minutes.
I'm looking forward to you making the setting boot-time configurable.
From your point of insight, what would you say: Does it depend on the CPU's frequency, the number of cores or the product of both, on how to chose the best CONFIG_SCHED_TIMESLICE ?
BR, Manuel
On my system (Kubuntu 20.04, SSD Samsung 860 Evo M2) with CONFIG_SCHED_TIMESLICE=2 login happens so quickly that password from SDDM isn't readed by KWallet so it's asked to unlock keyring :) That's probably KDE problem but maybe it's better to return to safer value 4? (which is "default" but won't be used since I guess most of the MuQSS/BMQ/PDS users also use PREEMPT).
ReplyDeleteAnd second proposition is to merge small patch (https://github.com/OpenMandrivaAssociation/kernel-release/blob/master/MuQSS-export-can_nice-for-binder.patch). Without it distro kernels with Android Binder module (Ubuntu, Debian, OpenMandriva) won't compile.
@@ -3529,6 +3529,7 @@ int can_nice(const struct task_struct *p
return (nice_rlim <= task_rlimit(p, RLIMIT_NICE) ||
capable(CAP_SYS_NICE));
}
+EXPORT_SYMBOL_GPL(can_nice);
#ifdef __ARCH_WANT_SYS_NICE
@Alte
DeleteThanks for reporting. I'll like the default setting more aggressive for desktop usage. Let's see if there are other side cases report later, then to determine whether to fallback to safer values.
For your second proposition, as mainline doesn't export symbol "can_nice", and drivers/android/binder.c should use "can_nice" without exporting. To keep the code changes focus only on BMQ scheduler itself, I would not export this in BMQ patch. But if 3rd party want to export this symbol for any reason, they can always use similar patch upon BMQ one.
@Alfred
DeleteYes, you're right, it's a Debian patch ( https://salsa.debian.org/kernel-team/linux/blob/master/debian/patches/debian/export-symbols-needed-by-android-drivers.patch, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901492 ).
https://github.com/xanmod/linux/commit/2aade5aceb89e84fec8b7c7ca401b3261571d47b
DeleteYou might have forgoten to tag the last two releases: https://gitlab.com/alfredchen/linux-bmq/-/tags
ReplyDeleteThank you for your hard work!
@Mystic
DeleteThanks for the reminding. Forgot to push the tags. Have fixed.