On Apr 9, 2013, at 7:39 PM, Craig Small <csmall-procps@xxxxxxxxxx> wrote: > I'd flip the logic and make numa off by default. Otherwise I'd have to > pull-in libnuma1 into procps dependencies which is not a good thing for > a base package to do. I would assume most people don't need numa > on by default and the principle of least-surprise is to not have it > enabled. Hi Craig, Here's that build-sys patch with numa support off by default. What worries me is how many distros may not bother to enable numa support even though they ship libnuma anyway. My instincts tell me this is a very important procps enhancement. Currently there is no easy way to quickly assess cpu usage in those environments where numa is likely to be used (massively parallel machines). The existing top is limited to screen rows for individual cpu stats while the remainder just get truncated in such environments. Besides, those stats become less useful the more cpus there are. And while NUMA may be directed primarily to memory issues, the ability to group and summarize cpus seems an even more important (to procps) side effect. That's why I thought 'on' by default might be the way to go. Looks like you'll have to make the final call. Regards, Jim
Attachment:
0001-build-sys-in-top-program-enable-NUMA-Node-extensions.patch
Description: Binary data
