On Sep 22, 2010, at 4:38 AM, Brice Goglin wrote:
> There are still some problems to solve in the membind branch:
> * Some OS bind the process too when you bind memory. I see the following
> + Add a flag such as HWLOC_MEMBIND_EVEN_IF_FAR_FROM_PROCESS so that
> the user can explicitly refuse memory binding if it may break process
> + Drop hwloc_set_membind on these OSes and add a
> hwloc_set_cpumembind() to bind both
> + Make both process and memory binding do nothing if the STRICT flag
> is given. But I'd rather not play too much with this flag.
> + Drop support for memory binding on these OS.
> + Drop these OS.
What OS's are you specifically referring to?
I think we should support memory binding, even if it does weird things -- i.e., dropping membinding support on a given OS shouldn't be an option. How about adding a query function that says what will happen for hwloc_set_membind() -- bind the memory, or bind the memory + the process? And/or have an "atomic"-like function that sets the memory binding and returns the process memory binding?
Just curious -- on these OS's, what happens if you:
- bind proc to A
- bind memory to B (which then also re-binds proc to B)
- re-bind proc to A
Is the memory binding then lost?
> * cpuset and nodeset structures are the same, they are both manipulated
> with hwloc_cpuset_foo functions. So maybe rename into hwloc_set_t and
> hwloc_set_foo functions. With #define and aliases to not break API/ABIs.
I'm in favor of this -- it would end the overloading of the term "cpuset" between hwloc and cpuset.
It would be good to put a sunset date or version on when hwloc_cpuset_foo will expire (e.g., 6 months from now or two major revisions form now [1.3] -- whichever comes last...?). I'd also prefer a typedef than a #define for types (vs. a #define).
For corporate legal information go to: