Messages in this thread | | | Date | Tue, 29 Oct 2019 16:34:47 -0400 | From | Julien Desfossez <> | Subject | Re: [RFC PATCH v3 00/16] Core scheduling v3 |
| |
On 29-Oct-2019 10:20:57 AM, Dario Faggioli wrote: > > Hello, > > > > As anticipated, I've been trying to follow the development of this > > feature and, in the meantime, I have done some benchmarks. > > > > I actually have a lot of data (and am planning for more), so I am > > sending a few emails, each one with a subset of the numbers in it, > > instead than just one which would be beyond giant! :-) > >
Hi Dario,
Thank you for this comprehensive set of tests and analyses !
It confirms the trend we are seeing for the VM cases. Basically when the CPUs are overcommitted, core scheduling helps compared to noHT. But when we have I/O in the mix (sysbench-oltp), then it becomes a bit less clear, it depends if the CPU is still overcommitted or not. About the 2nd VM that is doing the background noise, is it enough to fill up the disk queues or is its disk throughput somewhat limited ? Have you compared the results if you disable the disk noise ?
Our approach for bare-metal tests is a bit different, we are constraining a set of processes only on a limited set of cpus, but I like your approach because it pushes more the number of processes against the whole system. And I have no explanation for why sysbench thread vs process is so different.
And it also confirms, core scheduling has trouble scaling with the number of threads, it works pretty well in VMs because the number of threads is limited by the number of vcpus, but the bare-metal cases show a major scaling issue (which is not too surprising).
I am curious, for the tagging in KVM, do you move all the vcpus into the same cgroup before tagging ? Did you leave the emulator threads untagged at all time ?
For the overhead (without tagging), have you tried bisecting the patchset to see which patch introduces the overhead ? it is more than I had in mind.
And for the cases when core scheduling improves the performance compared to the baseline numbers, could it be related to frequency scaling (more work to do means a higher chance of running at a higher frequency) ?
We are almost ready to send the v4 patchset (most likely tomorrow), it has been rebased on v5.3.5, so stay tuned and ready for another set of tests ;-)
Thanks,
Julien
| |