BMQ 0.92 is released with the following changes
1. Rework boost/deboost task and thresholds.
2. Rework yield(). By introducing skip task in rq structure and skip schedule it in __schedule(). This should fulfilled the response to yield() and the long existed yield problem should be fixed.
This is yet another improvement release of BMQ. There are other bug fixes/improvement on going but ready to be released.
Enjoy BMQ 0.92 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.
NOTICE:
Some untested code are stealth in the yield() rework commit, emergency fix at
https://gitlab.com/alfredchen/linux-bmq/commit/1b66bf997e19f3fa59e0871cce0de4778e91bce3
up and running on 2 machines no problems so far.
ReplyDeleteAtleast with intel graphics opengl seems to be broken. I get strange hangs. I will check if this is related to the yield changes by reverting.
DeleteReverting back to 0.91 helped no more hangs.
ReplyDeletePls check with mainline CFS, will provide further improvement patch based on the feedback.
DeleteCFS was fine but your yield revert patch fixed the problem.
Delete"yield revert patch" means https://gitlab.com/alfredchen/linux-bmq/commit/1b66bf997e19f3fa59e0871cce0de4778e91bce3 ?
Deleteyes
DeleteDoes this mean /proc/sys/kernel/yield_type=2 is supported, or a fixed/improved yield_type=1?
ReplyDeleteCurrent, it replaces previous yield_type=1. May revert back the original yield_type 1 implementation and implement this as yield_type=2.
Deletehi Alfred!, i have problem, when i starting apps ncmpcpp, gedit, my system freezes for 30~60 seconds, with yield_type=1/2.
ReplyDeleteyield_type=0 fixed this issue, i know yield_type=0 not recommended for using.
*waiting fix*
on bmq091+patch system works great! (amd ryzen 5 2600)
ReplyDeleteFor those who have issue with BMQ092. Please read the NOTICE at the tail of post and apply the emergency patch.
ReplyDeletethanks! works perfectly!
DeleteIs it possible to adapt BMQ to the 4.19? I would have to backported pressure stall information or something else? Is this a difficult task?
ReplyDeleteSorry. My bandwidth is limited, so I can't commit any LTS kernel backport.
Delete@Alfred,
ReplyDeleteI tried playing D3 on BMQ - heavy stutters with tickless idle and full tickless.
Hopefully this will be taken care of later down the road :)
Thanks.
BR, Eduardo
@Eduardo
DeleteDoes D3 on wine relate to yield() code change? I have worked on stutter issue, but I'd like to confirm yield code changes before focusing on the others.
@Alfred,
DeleteIf I remember correctly, 0.91 worked w/o issues, 0.92 stutters. I tried running KVM virtualization on 0.92 it as well, stutters like in D3.
P.S. I don't play D3 at all these days, I just test schedulers on it, because of good test case :)
BR, Eduardo
@Alfred,
DeleteI did an experiment - I reverted all yield related commits, that is fix and rework. Compiled with full tickless (did not have time for tickless idle, but I reckon it doesn't matter much in this case) and stutter is gone from D3 :)
So the culprit was new yielr code.
BR, Eduardo
Would you pls list which commits you had reverted?
DeleteI reverted these commits in this order:
ReplyDelete1. 1b66bf99
2. 3ecf5a12
BR, Eduardo
Have you tried yield_type = 0?
DeleteNot, I haven't, I don't play with yield_type anymore :) I'll try at some point, if You suggest so.
DeleteBR, Eduardo
@Alfred and all other people on here:
ReplyDeleteI have this one running for now 5 1/2 days with nightly hibernations.
Today I've made a severe experience that reminds me of pre-PDS days, that making heavy use of a /dev/shm that is backed by swap space heavily impacts whole system usability.
Notes:
(1) The /dev/shm never reached it's max. content vs. size, but I had to process many files (decode-to, edit, decode-back, delete) today. Suddenly the system starved for about 15 minutes, but then it came back. No errors logged.
(2) I haven't noticed this with PDS, but maybe the hibernation cycles there haven't been stable enough to allow 5 1/2 days of uptime to show up this memory-aging(?) effect.
(3) I also store the Firefox Cache on /dev/shm and this is normally the first application to stall at first and then notify about failing script(s) execution via popup.
Anyway, can someone of you, please, tell me how I can safely calm down the swapping processes somehow?
Should I use "nice" or some other method?
Many thanks in advance,
Manuel
Another tool to test schedulers in "gaming" workflow. The script is used to test/improve VariableRefreshRate implementations and also to visual research. github.com/kleinerm/VRRTestPlots
ReplyDelete@Alfred:
ReplyDeleteToday I've seen your recent commits regarding BMQ v0.93 and the all-in-one patch in your gitlab repositories.
Are they ready to use or is there any reason to hold back an announcement?
Best regards,
Manuel
Just too busy to publish the announcement at that time.
Delete