[hwloc-devel] Create success (hwloc r1.1a1r2491)
Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.1a1r2491 Start time: Wed Sep 22 21:01:04 EDT 2010 End time: Wed Sep 22 21:03:14 EDT 2010 Your friendly daemon, Cyrador
Re: [hwloc-devel] roadmap
Jeff Squyres, le Wed 22 Sep 2010 13:37:12 +0200, a écrit : > 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. That's why I'd tend to keep set_cpubind and set_membind, warning that one may have impact on the other, providing a flag for those who really care, and a binding guideline for normal users. > And/or have an "atomic"-like function that sets the memory binding and > returns the process memory binding? I'm not sure to understand what this means. > 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...?). Ok. > I'd also prefer a typedef than a #define for types (vs. a #define). Sure. Samuel
Re: [hwloc-devel] roadmap
Le 22/09/2010 16:30, Jeff Squyres a écrit : > On Sep 22, 2010, at 8:09 AM, Brice Goglin wrote: > > >> hwloc_set_*? hwloc_objset* ? Anything better? >> >> hwloc_set_* might not be the best since we would have a hwloc_set_set() >> function to set one bit :) >> > Agreed. Too bad, though -- I liked hwloc_set*. > > hwloc_group* (that seems kinda lame, though) > hwloc_stuff* (hah) > hwloc_bitmap* > > ? > bitmap or bitmask would be acceptable to me. >> By the way, hwloc_cpuset_cpu() and hwloc_cpuset_all_but_cpu() should be >> renamed too. hwloc_set_onlyone() and hwloc_set_allbutone() maybe? >> > How about just hwloc_set() which takes a single position parameter? > "onlyone" can be implied. > In case you missed it: cpu() = zero() + set() and all_but_cpu() = fill() + clr() Maybe just drop these? Brice
Re: [hwloc-devel] roadmap
On Sep 22, 2010, at 8:09 AM, Brice Goglin wrote: > hwloc_set_*? hwloc_objset* ? Anything better? > > hwloc_set_* might not be the best since we would have a hwloc_set_set() > function to set one bit :) Agreed. Too bad, though -- I liked hwloc_set*. hwloc_group* (that seems kinda lame, though) hwloc_stuff* (hah) hwloc_bitmap* ? > By the way, hwloc_cpuset_cpu() and hwloc_cpuset_all_but_cpu() should be > renamed too. hwloc_set_onlyone() and hwloc_set_allbutone() maybe? How about just hwloc_set() which takes a single position parameter? "onlyone" can be implied. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] roadmap
Brice Goglin, le Wed 22 Sep 2010 10:38:38 +0200, a écrit : > * Some OS bind the process too when you bind memory. Not for all kinds of memory bindings. For now, nothing that has been commited does that, it's only the remaining TODOs. The bindings in question are policy binding, i.e. not binding some given area or explicitly allocating some given size. > + Add a flag such as HWLOC_MEMBIND_EVEN_IF_FAR_FROM_PROCESS The length of the word tells me that won't be convenient :) > 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 That's the solution I prefer most as it directly maps to existing OS practice > + 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. Yes. We should not put too vague semantic on this. > + Drop support for memory binding on these OS. Not all support, just setting the policy. > + Drop these OS. Nope :) > * 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'd say so. Samuel
Re: [hwloc-devel] roadmap
Le 22/09/2010 13:36, Jeff Squyres a écrit : > 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? > IIRC, it was AIX and Solaris. > How about adding a query function that says what will happen for > hwloc_set_membind() I like it, we can put this in the output of hwloc_topology_get_support. I wonder if there are some other cases where the STRICT flag could be dropped in favor of such an informative stuff. > 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? > I'll let Samuel comment on this. >> * 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. > hwloc_set_*? hwloc_objset* ? Anything better? hwloc_set_* might not be the best since we would have a hwloc_set_set() function to set one bit :) By the way, hwloc_cpuset_cpu() and hwloc_cpuset_all_but_cpu() should be renamed too. hwloc_set_onlyone() and hwloc_set_allbutone() maybe? Brice
[hwloc-devel] roadmap
Hello, hwloc 1.0 was released in May. I think we should release 1.1 before SC10, which means doing a first RC within a couple weeks. trunk got many changes since 1.0, but nothing very important. trac says we're missing memory binding, distances and user-defined process restrictions. Memory binding is the most important one, it was supposed to be in 1.0. I think we shouldn't defer 1.1 because of the others. 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. * 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. Opinions ? Brice
Re: [hwloc-devel] hwloc powerpc rhel5 and power7 patch
On 21/09/10 19:34, Samuel Thibault wrote: Just a last question: is it ok to include the /proc and /sys trees you have posted in the hwloc testcases? That's ok.
