Change in vdsm[master]: numa: move cpu topology (numa) related functionality to sitelib
mpolednik at redhat.com
mpolednik at redhat.com
Mon Feb 15 12:14:22 UTC 2016
Martin Polednik has posted comments on this change.
Change subject: numa: move cpu topology (numa) related functionality to sitelib
......................................................................
Patch Set 4:
(5 comments)
https://gerrit.ovirt.org/#/c/53287/4//COMMIT_MSG
Commit Message:
Line 8:
Line 9: The functionality can be nicely isolated and moved to sitelib, where
Line 10: additional cleanup and optimization work can take place. This is part
Line 11: of bigger series that attempts to move all numa related code to
Line 12: sitelib where it makes sense.
> looks identical to parent's commit message. Intentional? Am I missing somet
it is kind of supposed to be identical as the previous patches were meant to
1) unify and isolate numa-topology related functionality and
2) move it to it's own module.
Since cpu-topology related functionality is already nicely isolated, the patch is supposed to be identical to idea in 2) but aimed at cpu topo.
Line 13:
Line 14: Change-Id: Ie786e8a3626dd257c2a244decfe3e6a127d04b28
https://gerrit.ovirt.org/#/c/53287/4/lib/vdsm/numa.py
File lib/vdsm/numa.py:
Line 91: cells = host.find('.//cells')
Line 92:
Line 93: sockets = set()
Line 94: siblings = set()
Line 95: onlineCpus = []
> let's use pep8 names
Done
Line 96:
Line 97: for cpu in cells.iter(tag='cpu'):
Line 98: if cpu.get('socket_id') is not None and \
Line 99: cpu.get('siblings') is not None:
Line 100: onlineCpus.append(cpu.get('id'))
Line 101: sockets.add(cpu.get('socket_id'))
Line 102: siblings.add(cpu.get('siblings'))
Line 103:
Line 104: topology = {'sockets': len(sockets),
> nice, but I believe
Done
Line 105: 'cores': len(siblings),
Line 106: 'threads': len(onlineCpus),
Line 107: 'onlineCpus': onlineCpus}
Line 108:
Line 105: 'cores': len(siblings),
Line 106: 'threads': len(onlineCpus),
Line 107: 'onlineCpus': onlineCpus}
Line 108:
Line 109: return topology
> does it make sense to transform this into a namedtuple (perhaps into anothe
It probably does, and followup patch brings us closer to that. I'll consider it in later patches.
https://gerrit.ovirt.org/#/c/53287/4/vdsm/caps.py
File vdsm/caps.py:
Line 421:
Line 422: caps['kvmEnabled'] = str(os.path.exists('/dev/kvm')).lower()
Line 423:
Line 424: if config.getboolean('vars', 'report_host_threads_as_cores'):
Line 425: caps['cpuCores'] = str(numa.cpu_topology()['threads'])
> nit/personal taste: I'd invoke it once and dispatch the fields from the ret
Agreed.
Line 426: else:
Line 427: caps['cpuCores'] = str(numa.cpu_topology()['cores'])
Line 428:
Line 429: caps['cpuThreads'] = str(numa.cpu_topology()['threads'])
--
To view, visit https://gerrit.ovirt.org/53287
To unsubscribe, visit https://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ie786e8a3626dd257c2a244decfe3e6a127d04b28
Gerrit-PatchSet: 4
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Martin Polednik <mpolednik at redhat.com>
Gerrit-Reviewer: Francesco Romani <fromani at redhat.com>
Gerrit-Reviewer: Jenkins CI
Gerrit-Reviewer: Martin Polednik <mpolednik at redhat.com>
Gerrit-Reviewer: gerrit-hooks <automation at ovirt.org>
Gerrit-HasComments: Yes
More information about the vdsm-patches
mailing list