[procps] Re: top: NUMA node CPU utilization support
- From: Craig Small <csmall-procps@xxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Thu, 25 Apr 2013 19:27:38 +1000
On Wed, Apr 24, 2013 at 01:16:16PM +0200, Dr. Werner Fink wrote:
> For the libnuma support in top it could be an option to make this
> not only a build/compile option but also a runtime option. OK this
> may required some magic like to declare the functions numa_max_node()
> and numa_node_of_cpu() as weak symbols and load the libnuma.so.1 on
> demand if available but this may at least solve the problem that
> most desktop users are not interested in NUMA support.
I was thinking of that idea myself, I'm not sure how "robust" it is.
I actually have a project (gjay) that uses this sort of thing using
dlopen() and dlsym(). I've never had problems with it but it is fiddly
as all your functions turn into pointers and its not pretty like how
python does it (python doesn't care).
That would be kind of cool as if you need it, you got it, but if you
don't then it doesn't matter. I'm also not sure if it slows things down
that much. gjay is a Gtk application so its start-up is already slow so
you wouldn't notice :)
Distributions would depend on libprocps, libncurses and libc but would
have a weak dependency, similiar to Debian's "Suggests" on libnuma.
Maybe a quick check to see dlsym or whatever mechanism is ok and then
make the adjustments if its not too difficult. I'd still prefer it to be
off by default because this is the path of least surprise and is not
something essential, but distributions can enable it pretty simply.
Going this path means I could have a libnuma 'potientially available'
package in Debian, while the hard dependency has a lot of problems.
- Craig
--
Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Other related posts:
