VRQ 0.90 is released with the following changes
1. Introduce sched_yield_type from MuQSS
2. Remove temp valuables in run queue for current task
3. Refine dither.
As there is no more previous vrq feature code need to be ported, I'd like to announce VRQ 0.90 release just before the new year. All known issues will be traced in 0.90+ releases.
In the 0.90+ release, I am planning to focus on fixing known issues, porting useful code changes from BFS/MuQSS and develop new features in VRQ.
Enjoy 0.90 release of VRQ in 2017, :)
code are available at
https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-4.9.y-vrq
and also
https://github.com/cchalpha/linux-gc/commits/linux-4.9.y-vrq
All-in-one patch is available too.
BR Alfred
What "known issues" do remain? So that we keep an eye on them?
ReplyDeleteBR, Manuel Krause
@Manuel
DeleteSorry for the late reply. Just get back home after the new year holiday.
Konwn issues are
1. D3 wine playing issue in acpi drivers ondemand governor reported by Eduardo. I have sent him a debug patch, and recived his test result and confirmed it solved the issue, but with this debug patch, sanity result shows there are performance regression under 50% workload. So I am still thinking another way to solve this issue.
2. As reported by jw7(?) Intel cpufreq driver may still broken with VRQ, I don't have time to test this yet.
That's all in my list for new version VRQ so far, #2 may not related to new VRQ.
BR Alfred
@Alfred:
DeleteYes, a happy new year to you all on here, too! :-)
What is the HZ value you would recommend for the VRQ kernels? I had been experimenting with some unusual values like 512 with MuQSS quite successfully.
Oh, and thank you for implementing sched_yield in VRQ, may make kernels more comparable.
Thanks in advance and BR,
Manuel Krause
@Alfred; the cpufreq thing was brought up by Eduardo (or Pedro) I think. I had the UP compile issue, which you resolved in 0.89h. I will hopefully build 0.90 tonight; thanks again!
Delete@jwh7
DeleteThanks, that must be Pedro.
@Alfred:
ReplyDeleteIt's a little sad. Since yesterday I was testing this new VRQ and I liked the overall interactive experience. But today, ~2-3 minutes after coming out of suspend-to-disk the desktop/ system hung up unexpectedly (after re-login to the KDE, connecting to the router and while reloading a FF browser page) without further notes. :-( No idea what may have went wrong.
BR, Manuel Krause
@Manuel
DeleteIs it reproducible? But if it happens after ~2-3 minutes after resume from suspend-to-disk, it's hard to blame to cpu hotplug/on/offline functionality.
Since the rework of cpu hotplug in the earlier VRQ 0.89 version, I am very confident with system suspend/resume on my systems, and the time use to be out of resume is reduced significantly comparing to previous implementation.
@Alfred:
DeleteI haven't found time to take the risk again, yet.
The MuQSS/ck for 4.9 hasn't shown up this issue during weeks of testing. My freshly built VRQ kernel setup only differs from the earlier in the VRQ patch and possible .config dependancy related differences. I wanted to read a first estimation from you, before I'll give it another try tonight, and then come back.
BR, Manuel Krause
@Alfred:
DeleteCompleted two successful successive resumes from disk now without following issues. Same scenario, except for hibernating over night, that I'd tell you tomorrow. Btw. my system's software/ hardware hasn't changed during all the mentioned periods of testing.
But, how should I handle the possible risk of failure in my mind? ^^
As I said before, your VRQ evolution in general behaves extremely good on here, and I thank you very much for your continued work on it in face of all the MuQSS "hype" during the last months, that I was addicted to, too.
BR, Manuel Krause
@Alfred:
ReplyDeleteThere still remain basic issues with the current VRQ:
Just compiling a kernel with -j2 on my dual core with your VRQ...
Only first cpu gets 100% load, second is at around 30% and serving the "idle" load of my wcg. Old topic ... reloaded??
And regarding other concerns: System remains very interactive.
BR, Manuel Krause
@Manuel
DeleteYes. You are with a negative senario of task policy fairness. Definitely we need a good solution for that. I'd try some new idea next week.
@Alfred:
DeleteThank you for taking care of it. I'm looking forward to your good solution and will test it when it's available. No need to rush. In spite of my previous error posting: it may have been a one time error: my system is stable and very interactive with this VRQ.
BR, and happy developing,
Manuel Krause