Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] roadmap
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2010-09-22 07:36:37

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
> solutions:
> + 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
> binding
> + 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).

Jeff Squyres
For corporate legal information go to: