Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

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
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/