On Thu, Dec 10, 2015 at 5:07 PM, Martin Polednik <mpoled...@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel