Jeff Squyres, le Tue 04 Jan 2011 22:22:41 +0100, a Ã©crit :
> What does "binding cannot be enforced" mean (i.e., when EXDEV is returned)?
It's explained in more details in the header of the documentation
âerrno is set to EXDEV when the requested cpuset can not be enforced
(e.g. some systems only allow one CPU, and some other systems only allow
one NUMA node).â
I.e. it's the given combination of cpus or nodes which the OS doesn't
support, typically because the combination crosses some device boundary,
thus the choice of EXDEV.
> Assumedly the system supports binding (otherwise ENOSYS would have been returned). Does it mean, for example, that I asked for X memory on node Y, but node Y didn't have X memory available on node Y?
That case would rather be OS-dependent.
> When EXDEV is returned, is valid memory returned (that must be freed via hwloc_free), or does the entire allocation fail?
It completely fails. But as documented in the header of the
documentation section, that only happens when STRICT is passed.
> Is the purpose of these 2 functions to query the memory binding policy for an (addr, len) tuple in the current process?
> If so, what happens if there are multiple memory binding policies in effect for that tuple?
It seems I forgot to copy/paste the documentation from the CPU part
about the STRICT flag, I've commited it:
âWhen retrieving the binding of a memory range, this flag checks
whether all its pages actually have the same binding. If the flag is
not given, the binding of each page will be accumulated.â
> What is the purpose of the IN flags argument?
Answered above :) At least the STRICT flag.
> Taking a guess: can you pass _PROCESS or _THREAD in to query the binding policy for this specific thread or the entire process? (and all other flags are ignored or illegal?)
It does not make sense in the case of area_get_membind, since memory
binding for an area is related to the area, not to who accesses it (even
in the firsttouch case, where the policy is firsttouch).
> Is the purpose of these 2 functions to query the memory binding polocy for the entire current process (or a thread in the current process)?
Ah, that part of the cpubind documentation didn't get copied
either. I have commited it:
âWhen neither HWLOC_MEMBIND_PROCESS nor HWLOC_MEMBIND_THREAD
specified, the current process is assumed to be mono-thread. This is the
most portable way as it permits hwloc to use either process-based OS
functions or thread-based OS functions, whichever are available.â
> It took me a while to notice the PID argument in this function, and that this was the main difference from hwloc_get_membind*. I assume that the documentation statement "Get current process memory binding in cpuset cpuset." is actually incorrect -- right?
Oops, indeed. That's the problem with painfully documenting a big series
of very similar functions...
> It shouldn't say "current" -- it should indicate that you can query the memory binding policy for the process specified by the pid argument, right? If so, is it equivalent to calling hwloc_get_membind* in that process?
> Assumedly, you need some kind of rights on the target process -- either you're the owner of the process, or are superuser, ...or have some other administrative rights on the target. Right?