VRQ 0.93 is released with the following changes
1. remove unused rq->running and refine set_rq_task(), remove unused finish_arch_switch, these two changes are continuous code clean up.
2. Fix 32bit compilation issue in cputime.c(reported by jwh7)
3. task policy fairness
Task policy fairness is the major code change in this release, which address the issue that NORMAL policy(and supper) tasks fail to suppress the background IDLE policy tasks. There are used to be two design options for this issue, but turns out that one of them is better than another with less overhead. So the code changes are in this VRQ release and no more debug patch is needed.
In next release, mainline kernel 4.10 sync-up and code clean-up are in the planning list. And I am investigating new created task issue, hopefully be fixed in next release.
Enjoy VRQ 0.93, :)
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
@Alfred:
ReplyDeleteThank you for the updated release. My first compile tests show, that your "task policy fairness" approach works well for me. I also don't see problems atm. with 0.93 VRQ.
The unbalanced cores' load still confuses me, please don't forget to give the promised explanation, why it's really intended in VRQ design.
And... What do you mean with "new created task issue"? How does it show up?
BR, and many thanks for your work!
Manuel Krause
Now, there could be some problem with the new created tasks for their deadline setting and selection of cpu to be run on. After resolving this, the explaination will be more persuration.
Delete@Alfred:
DeleteHopefully, you would find time to take care of it already for the 4.9 kernel -- and not push it to 4.10.
I do just consider the severe BUG/ patch flood that came with 4.9.0. Somewhere I've read that 4.9 will be a LTS one.
BR, Manuel Krause
Build for x64 was fine but I still get compile errors, now in kernel/sched/bfs.c:
ReplyDeletehttps://gist.github.com/jeremywh7/0c931656e0ba25a64821c46e89ac143e
Ok, that's new code for task policy fairness. I should compile it on raspberry pi(32bits) before release.
Delete@jwh7
DeleteI have pushed the fix to git, plz check it out at
https://bitbucket.org/alfredchen/linux-gc/commits/7935285fbc501d3a76a4b98e974d3ce10cddac45?at=linux-4.9.y-vrq
32-bit UP compiles file now; thanks Alfred. I haven't booted it yet though.
Delete@Alfred,
ReplyDeleteI have tested 0.93 + 4.9.9 in different computers. On almost all of them I see CPU time accounting problems in "top", totals are always higher than CPU usage for individual tasks, that was very visible under low power machine (some Celeron B830 or so), couple of tasks showed 2% usage, the rest 0, but overall system usage was at least 30% of each core.
As noone else seems to have this problem, maybe that's my compilation issue, I compile with 100Hz, nothing unusual, the same as all the time. Alfred, did U notice this?
With Core2Duo + nVidia + opening steam => complete crash, every time with nothing in the console, that computer is switched to mux now.
On Phenom / Skylake all seems to be working w/o crashes.
Can't speak of new created task issue as I don't know where to look for it and core load balancing is not really an issue for me right now (I don't know whether that is an issue at all in my workloads), waiting for design explanation You promised :)
Br, Eduardo
I had similar problems using 0.92.
Delete@Alfred,
DeleteHere is CPU usage at about the same place in LOL, You can see a big difference in CPU sums, in mux it's aligned in vrq not so much...
VRQ link: http://pasteboard.co/xYIywINUy.png
MUX link: http://pasteboard.co/xYVg41J1I.png
P.S. I'll not bother You anymore with those sums, just this last handy example :)
Br, Eduardo
@Eduardo
DeleteFor the cpu sums behaviors, would you also check the same behaviors in mainline CFS? Yes, I do notice the cpu sums are different than it used to be after introducing the mainline cputime.c, but I cross-referencing it with mainline CFS, in my test case, it is similar to CFS, so I just let it be.
Better try to copy MUQSS (instead of CFS) where cpu/load balancing is close to perfect.
Delete@Alfred,
DeleteThis is for Ubuntu 4.8.3 (mainline) kernel and it's rather aligned: http://pasteboard.co/3tw4v4QQq.png
So at least what I see, there is a CPU accounting time problem in VRQ...
I may agree with Anon, maybe it's better to use mux accounting maybe...
Br, Eduardo
@Eduardo
DeleteThanks for the testing and reporting. I will double check the commit of introducing cputime.c. I must missed some accounting for tasks.
Hi Alfred,
ReplyDeleteI've done new throughput benchmarks of VRQ0.93 on linux 4.9.9.
This time I've used a custom mariadb package along with sysbench 1.0.1.
Results are here as usual:
https://docs.google.com/spreadsheets/d/163U3H-gnVeGopMrHiJLeEY1b7XlvND2yoceKbOvQRm4/edit?usp=sharing
On a side note, I've made some scaling tests with CFS and MuQSS, to see why MuQSS is performing poorly under half load.
They are in the '4.9.9 Scaling test' sheet.
It might be of interest for your work on VRQ.
I've written my findings on CK's blog.
Pedro
Bring up an eaten post by Pedro
ReplyDelete>Hi Alfred,
>I've done new throughput benchmarks of VRQ0.93 on linux 4.9.9.
>This time I've used a custom mariadb package along with sysbench 1.0.1.
>
>Results are here as usual:
>https://docs.google.com/spreadsheets/d/163U3H-gnVeGopMrHiJLeEY1b7XlvND2yoceKbOvQRm4/edit?usp=sharing
>
>On a side note, I've made some scaling tests with CFS and MuQSS, to see why MuQSS is >performing poorly under half load.
>They are in the '4.9.9 Scaling test' sheet.
>It might be of interest for your work on VRQ.
>I've written my findings on CK's blog.
>
>Pedro
@Pedro
DeleteThanks again for the testing. I'd check 50% workload cases with CFS and find it out if it is related to cpu topology or not. Based on my previous tests, VRQ should be closed to CFS under 50% workload on my test machine(non-HT). So, my best guess, VRQ may select HT cpus which lead to poor performance. Will let you know the result once it is done.