[ovirt-devel] CPU sockets, threads, cores and NUMA

[Yaniv Kaul]

On Thu, Dec 10, 2015 at 5:07 PM, Martin Polednik <mpolednik at redhat.com>
wrote:

> Hello developers,
>
> tl;dr version:
> * deprecate report_host_threads_as_cores
> * remove cpuSockets, use sum(numaNodes.keys())
> * report threadsPerCore for ppc64le / report total number of threads
>  for ppc64le
> * work on our naming issues
>
> I've been going over our capabilities reporting code in VDSM due to
> specific threading requirements on ppc64le platform and noticed few
> issues. Before trying to fix something that "works", I'm sending this
> mail to start a discussion regarding current and future state of the
> code.
>
> First thing is the terminology. What we consider cpu sockets, cores and
> threads are in fact NUMA cells, sum of cores present in NUMA
> nodes and the same for threads. I'd like to see the code moving in a
> direction that is correct in this sense.
>

Note that I think users are more familiar with sockets-cores-threads than
NUMA cells, terminology-wise.


>
> More important are the actual calculations. I believe we should draw
> an uncrossable line between cores and threads and not interfere with
> it at least on VDSM's side. That would mean deprecating
> report_host_threads_as_cores option. The actual algorithm used at
> present does calculate the numa cores and numa threads correctly given
> that there are no offline CPUs - most likely fine enough. We don't
> have to report the actual number of sockets though, as it is reported
> in numa* keys.
>

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.
I don't think we should deprecate it.


> It does fail to provide us with information that can be used in
> ppc64le environment, where for POWER8 we want to run the host without
> SMT while VMs would have multiple CPUs assigned. There are various
> configurations of so-called subcores in POWER8, where each CPU core
> can contain 1, 2 or 4 subcores. This configuration must be taken in
> consideration as given e.g. 160 threads overall, it is possible to run
> either 20 VMs in smt8 mode, 40 VMs in smt4 mode or 80 VMs in smt2
> mode. We have to report either the total number of threads OR just the
> threadsPerCore setting, so the users know how many "CPUs" should be
> assigned to machines for optimal performance.
>

YAY... do we have a comparison what libvirt knows / looks at (or they
ignore it altogether?)
Y.


>
> As always, I welcome any opinions regarding the proposed ideas. Also
> note that all of the changes can be done via deprecation to be fully
> backwards compatible - except for the ppc part.
>
> Regards,
> mpolednik
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20151210/4782b3e3/attachment-0001.html>