BMQ 0.91 is released with the following changes
1. Fix BMQ compile fails for x86-UP, again. Thanks pf's code review.
2. treat NORMAL task as dl for lower ttwu latency.
3. Remove uprq. Unified code base for UP and SMP.
4. Rework task switch time thresholds.
5. Rework sg_balance_trigger(). Add one more trigger scenario.
This is improvement release of BMQ. #4 will provide more distributed boost range, users can notice this by watching the cpu monitoring tools.
Enjoy BMQ 0.91 for v5.0 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.
Please report bugs at https://gitlab.com/alfredchen/bmq/issues.
@Alfred:
ReplyDeleteCompiled and booted fine with kernel 5.0.4, now works well for me for ~6h.
It's quite difficult to distinguish differences to BMQ 0.90, but I don't experience any regression. :-)
You've done great work with the new BMQ scheduler!
Best regards,
Manuel
Hi @Alfred, it's i anon with problem vulkan, with patch https://gitlab.com/alfredchen/linux-bmq/commit/3cf2f8b7d97a565764cf42132522266db5f86739 and bmq091, result after a time system unfreezed, (aka system not fully dead, this is the best result, with what was), *waiting yield_type 2* good luck @Alfred!
ReplyDeleteand after unfreeze game dead(black screen), needed restart.
DeleteThanks for the feedback. Will work for another yield solution.
DeleteDid some tests with yield_type, and found that when doing a benchmark + a make -j12 in the background, the default yield_type of 1 had a horrible result.
DeleteSetting yield_type to 0, + the nVidia driver with __GL_YIELD="USLEEP" seemed to get the best benchmark score.
Previously this USED to be with yield_type=2, but that is not available as you say.
The benchmark was run with -5 nice value, so in theory a yield_type of 1 should have given a better result for the -5 task (the benchmark) right? (This is with BMQ 0.91 + the above patch).
Up to experimentation i guess.
Built and running on x86-UP netbook; thanks Alfred!
ReplyDeleteThanks.
ReplyDeleteThanks.
ReplyDeleteNice performance but can you please make the timeslice tunable?
For slower CPUs or server use it would be better to increase/adjust it.
CONFIG_SCHED_TIMESLICE is tunable, but it's not recommended b/c some thresholds based on timeslice is still not finalized.
DeleteOK.
DeleteThanks for answering.
I meant tuning at runtime.
Compiling a new kernel each time seems rather time intensive.
Alfred, can you suggest the optimal settings for:
ReplyDelete- Hz: periodic, no_hz, no_hz_full
- Preemption: server, desktop, preempt
- Tick frequency: 100, 250, 300, 1000
Thank you!
This is probably individual, cos there are just as many recommendations from various kernelhackers as there are options.
DeleteLove to hear Alfred chime in on this ofc, as he would know a bit more what to expect from those tunables when it comes to BMQ.
However, from my own testing with PDS and some BMQ, i think i would conclude with the following: (This is for a DESKTOP rig used for gaming and whatnot)
Hz: no_hz (CONFIG_NO_HZ=y, CONFIG_NO_HZ_IDLE=y)
Preempt: preempt (CONFIG_PREEMPT=y)
Tick: 1000hz. (CONFIG_HZ_1000=y, CONFIG_HZ=1000)
You might get slightly better max perf from choosing hz=100 at the cost of a bit less "snappy" feel tho, so its more up to experimenting.
BMQ performs a wee bit different than PDS, so as i said, i would love to see a comment from Alfred ofc :)
Hi,
DeleteI've also made good experiences with the above settings for PDS. Some day I changed to CONFIG_HZ_PERIODIC=y for some reliability testing. The latter would be more energy consuming, as I understood it.
1000Hz are good for interactivity and PREEMPT should be mandatory for this goal, too.
Of course, you should test these parameters according to your needs.
For BMQ091 these settings work as well as with last PDS from @Alfred, IMHO.
But I'm curious for @Alfred's more experienced mind's answer on this, too.
Best regards,
Manuel
For the default kernel (without PDS or BMQ) on the Raspberry Pi 3:
DeleteHz: FULL
Preempt: Desktop
Tick: 300Hz
I then reserve the first core for all housekeeping and interrupt activity, which the emulators and supporting processes run without interrupt on the remaining 3 cores.
This provides the best balance between performance and latency. I'm also using these settings for BMQ now, but maybe Alfred will recommend some slight changes.
As discussed before, all these setting is related to system performance under certain usage. But they are not related to cpu scheduler itself. So I would like to not recommend these settings, and let the users to tune for their usage.
DeleteAnd it's good to see users have shared their settings here.
Hi, works OK on Ryzen 1700 and 2400G, both at home and ok on i7@work, BUT issue with sound crackling while saving libreoffice docs is still here since last releases of PDS. I use old school media player called Apollo37z (yes, that's old as old it can be :D) through wine.
ReplyDeleteAnnoying :(
BR, Eduardo
Hi, @Eduardo!
DeleteIs there a reason to use this way of media playback? I use smplayer (KDE) frontend for /usr/bin/mpv and don't experience any stuttering or crackling when having high loads (e.g. normal prio kernel compiling). Also media playback from german broadcasting websites through their various players within Firefox doesn't suffer.
Maybe time to change your media playback routine? ;-)
BR, Manuel
Agreed, you should give DeaDBeeF a try.
DeleteHi, @Manuel!
ReplyDeleteLet's look at this from different POV. This has not been a problem for me for like 9.6 years out of 10. Now, somehow, it starts to misbehave, but it's still an extremely simple application in wine and runs rather well on different schedulers.
The same argument of Yours could be applied to Diablo3, which I played back in the day and it stuttered, why don't change that to say OpenD2, which is native, right... Well, not exactly :)
I hope You see my point ;)
I'll try to use vanilla or muqss for a while to see whether similar symptoms appear there too. I'll post my findings.
BR, Eduardo
@Eduardo
DeletePls report bug to https://gitlab.com/alfredchen/bmq/issues
You reported similar issue for PDS if I remember correctly, and it has been fixed in PDS. It's caused by burst creating tasks which take too many cpu time and make other tasks starving. I'll see what can be done in BMQ.
@Alfred,
DeleteI'll do that, but I'll gather more info before.
BR, Eduardo
@Eduardo
DeleteYou can also try this workaround. Use "nice" cmd to adjust your music player priority. I believe nice --10 will be a good start point.