<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 10, 2015 at 5:07 PM, Martin Polednik <span dir="ltr"><<a href="mailto:mpolednik@redhat.com" target="_blank">mpolednik@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello developers,<br>
<br>
tl;dr version:<br>
* deprecate report_host_threads_as_cores<br>
* remove cpuSockets, use sum(numaNodes.keys())<br>
* report threadsPerCore for ppc64le / report total number of threads<br>
for ppc64le<br>
* work on our naming issues<br>
<br>
I've been going over our capabilities reporting code in VDSM due to<br>
specific threading requirements on ppc64le platform and noticed few<br>
issues. Before trying to fix something that "works", I'm sending this<br>
mail to start a discussion regarding current and future state of the<br>
code.<br>
<br>
First thing is the terminology. What we consider cpu sockets, cores and threads are in fact NUMA cells, sum of cores present in NUMA<br>
nodes and the same for threads. I'd like to see the code moving in a<br>
direction that is correct in this sense.<br></blockquote><div><br></div><div>Note that I think users are more familiar with sockets-cores-threads than NUMA cells, terminology-wise.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
More important are the actual calculations. I believe we should draw<br>
an uncrossable line between cores and threads and not interfere with<br>
it at least on VDSM's side. That would mean deprecating<br>
report_host_threads_as_cores option. The actual algorithm used at<br>
present does calculate the numa cores and numa threads correctly given<br>
that there are no offline CPUs - most likely fine enough. We don't<br>
have to report the actual number of sockets though, as it is reported<br>
in numa* keys.<br></blockquote><div><br></div><div>There is a reason for report_host_threads_as_cores option. I don't remember it right now, but it had to do with some limitation of some OS or license or something.</div><div>I don't think we should deprecate it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It does fail to provide us with information that can be used in<br>
ppc64le environment, where for POWER8 we want to run the host without<br>
SMT while VMs would have multiple CPUs assigned. There are various<br>
configurations of so-called subcores in POWER8, where each CPU core<br>
can contain 1, 2 or 4 subcores. This configuration must be taken in<br>
consideration as given e.g. 160 threads overall, it is possible to run<br>
either 20 VMs in smt8 mode, 40 VMs in smt4 mode or 80 VMs in smt2<br>
mode. We have to report either the total number of threads OR just the<br>
threadsPerCore setting, so the users know how many "CPUs" should be<br>
assigned to machines for optimal performance.<br></blockquote><div><br></div><div>YAY... do we have a comparison what libvirt knows / looks at (or they ignore it altogether?)</div><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As always, I welcome any opinions regarding the proposed ideas. Also<br>
note that all of the changes can be done via deprecation to be fully<br>
backwards compatible - except for the ppc part.<br>
<br>
Regards,<br>
mpolednik<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
</blockquote></div><br></div></div>