VRQ 0.96f is released with the following changes
1. Improvement for smt sensitive scheduling.
2. No dequeue/enqueue for task on cpu.
3. Code clean up.
#2 is the major change in this release, unlike the previous version, now when task is going to be run on a cpu, there is no need to dequeue the task from the run queue skip list, enqueue/dequeue will only happen when task become runnable/unrunnable. With this change, the overhead of enqueue/dequeue is significantly reduced, and the logic of scheduler is more simple.
And please also be noticed, to adapt to this new enqueu/dequeue strategy, some important code path has been rewriten. You may experience unstable issues with this release. (So far, none for me at least)
Enjoy VRQ 0.96f for
v4.12 kernel, :)
code are available at
https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-4.12.y-vrq
and also
https://github.com/cchalpha/linux-gc/commits/linux-4.12.y-vrq
All-in-one patch is available too.
It survived my smoke tests, so should be OK :).
ReplyDeleteThanks.
Hey Alfred,
ReplyDeletex64 built fine, but x86 fails with:
https://gist.github.com/jeremywh7/ee8a36b7cc580bbf7a9e2650d19b2e81
I assume this happens because of CONFIG_SMP=n, correct?
DeleteYes. It's SMP related, I am working on fix commit. Just waiting it to pass the SMP=N compilation before pushing it to git.
Delete@jwh7
DeleteThanks for reporting. I have pushed a fix commit to git, you can check it out at
https://bitbucket.org/alfredchen/linux-gc/commits/4372c4f37a7d200184d4f13657911e850b312c95
github also be updated.
Thanks Alfred; x86 (no SMP) builds fine now. :)
DeleteThanks Alfred.
ReplyDeleteMy usual benchmarks completed without problems.
Pedro
@Pedro
DeleteI saw your updated benchmarks. Although VRQ096f 1000Hz got two worst but from the value respect, it doesn't different that much. And I'd love to see -j4 compilation result, 10%, that really shows what smt sensitive scheduling feature does. The overall result of VRQ096f 1000Hz also looks good. Thanks for your effects of benchmarking, I have similar benchmark records, but it is more convincing when it comes from a 3rd party.
I will continue looking into any improvement can be made for 100% and 150% workload in the incoming release.
@Alfred:
ReplyDeleteThis seems to me to be a great piece of rework.
With the previous revision I've seen left/right stereo audio switching problems, but was not sure about the reason, it's gone. Also, the earlier mentioned WARNING:
-->
workqueue: PF_MEMALLOC task 8676(systemd-sleep) is flushing !WQ_MEM_RECLAIM i915:i915_gem_idle_work_handler [i915]
[ 8982.750618] ------------[ cut here ]------------
[ 8982.750623] WARNING: CPU: 0 PID: 8676 at kernel/workqueue.c:2418 check_flush_dependency+0x7a/0xfd
<--
is gone now (full trace snippet here: https://pastebin.com/h2DYrUwf).
Unfortunately I'm back in testing TOI, and don't want to interrupt the current testing row until it fails first time, to do cross checks with the three changes I've made to the currently running kernel. Is it possible that your actual changes made the issue go away?
Thank you for your work and BR,
Manuel Krause
@Manuel
DeleteIf you talking about the changes of enqueue/dequeue, those are most scheduler internal related.
Good luck with your TOI testing.
@Alfred:
DeleteYes, I thought of the enqueue/dequeue thing mainly, the other commits are unlikely to have effect on here (due to SMT dependency).
Regarding the TOI testing (thanks for your wishes!) I got up to 8 successful resumes in a row, remarkable, then facing a BUG with it, and No.9 failed to resume. I don't think it's related to VRQ, but have uploaded the trace, so you maybe comment if I'm right: https://pastebin.com/h9gjzcTi
Atm. I need to re-check whether I have all needed fixes for BFQ i/o scheduler in place, for which post-factum made a nice summary here:
https://groups.google.com/forum/?fromgroups=#!topic/bfq-iosched/1zoZu00b-C0
on Aug. 5th, before I proceed.
BTW, great thanks for your work, too, Oleksandr!
Best regards,
Manuel
Shame on me -- I really missed at least two early fix commits that appear really important.
DeleteRecompiling, then restarting the hibernation tests... BR, Manuel
I've used both ck and your patch when it was at v0.95 and both suffered similar inversion issues with wine and I wasn't sure how to debug it at the time.
ReplyDeleteA lot of time has passed, so I patched the new v0.96f and got netconsole ready; but saw absolutely no issues at all. I am very surprised how stable and responsive it is. Really amazing work!
I will continue testing to see if I run into any bugs and races.
@Tom
DeleteYes. Thanks for all who join the testing and feedback in recent releases. Now VRQ is more reliable than it used to be.
If the inversion issues you talk about is related to rtmutex or task priority boost, I happened to write a VRQ adaption for deadline in rtmutex last weekend and will be included in next release.
Hi,
ReplyDeleteworks fine on i7 for 3 days, multiple suspends in between and on Ryzen, for couple of days. Did not do any specific testing, but so far so good.
Also, I compile kernel now w/ 250Hz and NO_HZ_IDLE, that works very good for gaming on old Phenom II as well.
Thanks Alfred,
Br, Eduardo