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