Comment 2 for bug 1251209

James Hunt <email address hidden> writes:

> I've now got some code to display cpu affinity (using sched_getaffinity()).
>
> NUMA looks slightly more awkward for 2 reasons:
>
> 1) Although I've got some code that uses get_mempolicy(), that syscall
> requires libnuma (!)

I didn't realize that, but I don't use it directly.

> seemingly in my case only to give
> the correct platform-specific syscall number for get_mempolicy(). This seems to be somewhat overkill but I'll take a closer
> look tomorrow.
>
> 2) Testing: get_mempolicy() returns ENOSYS on non-NUMA systems (like
> mine :) Do you have access to NUMA hardware?

Around 350 systems of various types -- I do HPC and recommend procenv
for debugging possible environmental problems with batch jobs. The CPU
binding(/affinity) is actually a lot more important for my purposes than
memory affinity.

I can certainly test if it helps.

> Would the above suffice do you think or is there a compelling reason to
> use libhwloc?

It's possibly nice to have the logical values, but probably the only
compelling reason is if you want to support other kernels (even kfreebsd
in the Debian world?). Anything that basically says what cores you're
bound to would be useful, so that should suffice.