[hwloc-devel] Create success (hwloc r0.9.1a1r1050)
Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 0.9.1a1r1050 Start time: Wed Sep 30 21:01:05 EDT 2009 End time: Wed Sep 30 21:02:58 EDT 2009 Your friendly daemon, Cyrador
Re: [hwloc-devel] structure assumptions, duplication
Fawzi Mohamed, le Wed 30 Sep 2009 10:10:47 +0200, a écrit : > If you look at the example described in the document that I had linked > > http://opensolaris.org/os/community/performance/mpo_overview.pdf > > you see the that for a ring topology some level (that you always get adding > the Ah, right. Yes, we could also provide this as an additional structure. > For a the ring topology a-b-c-d-a is difficult to find a good partition... and > having both partition and non partition views (one used for resource > allocation > /distribution, the other for resource finding/stealing), is quite clean imho. Yes, heuristics would partition it into ((a,b),(c,d)), while non-partition could usefully provide all the related triplets. We can provide both. Samuel
Re: [hwloc-devel] structure assumptions, duplication
On 30-set-09, at 10:38, Brice Goglin wrote: Fawzi Mohamed wrote: NODE 1 cache2 cache1 p0 cache2 cache1 p1 NODE 2 cache1 p2 cache1 p3 or is it even possible to have a node with children of a single node of different depth? this is supposing that you want to keep that a level has a single type (and given the api I suppose it is so). We keep same caches in the same level. So node 2 has children at depth+2 instead of depth+1. thanks Brice, that is what I wanted to know. ciao Fawzi
Re: [hwloc-devel] structure assumptions, duplication
Fawzi Mohamed wrote: > NODE 1 > cache2 > cache1 > p0 > cache2 > cache1 > p1 > NODE 2 > cache1 > p2 > cache1 > p3 > > or is it even possible to have a node with children of a single node > of different depth? > > this is supposing that you want to keep that a level has a single type > (and given the api I suppose it is so). We keep same caches in the same level. So node 2 has children at depth+2 instead of depth+1. Brice
Re: [hwloc-devel] structure assumptions, duplication
On 30-set-09, at 09:29, Samuel Thibault wrote: Hello, Hi Samuel, Fawzi Mohamed, le Wed 30 Sep 2009 09:16:36 +0200, a écrit : 1) a fully hierarchical representation of the machine/hardware where each level is a partition, and each level fully covers the previous one (from any node you go through all levels using father/childrens, father/child are just one level away from each other. This is basically what is there now. 2) outside the hierarchy 1 (but built using its object, probably the NUMA nodes) there will be 2.1) maybe the full connection graph 2.2) a hierarchical view of it, like the lgroups, where the levels are not necessarily a partition, and that could also refer not to the sublevel, but directly to lower levels. Going up the hierarchy you get the next neighbors. Err, no, in our plans 2.2 was in 1) already, and levels are thus still partitions, but somehow arbitrary ones, according to heuristics based on the graph. Isn't that the case with lgroups ? (I haven't ever had access to a solaris numa machine) If you look at the example described in the document that I had linked http://opensolaris.org/os/community/performance/mpo_overview.pdf you see the that for a ring topology some level (that you always get adding the next neighbors) do not form a partition (i.e. they overlap), such an overlap unavoidable if to build the next higher hierarchy you simply add the next neighbors. Having a partition is very useful when, for instance instead of looking for a resource you want to restrict/pin a thread, for this reasons there are psets and lpls (lgroup partition loads, intersection of lgrops and processor partition, which are again a partition), and both are used on opensolaris. Well you don't have to mirror what solaris does, but I found that quite nice, so I was thinking you wanted to go in that direction. For a the ring topology a-b-c-d-a is difficult to find a good partition... and having both partition and non partition views (one used for resource allocation/distribution, the other for resource finding/stealing), is quite clean imho. ciao Fawzi
Re: [hwloc-devel] structure assumptions, duplication
On 30-set-09, at 09:20, Brice Goglin wrote: Fawzi Mohamed wrote: 1) a fully hierarchical representation of the machine/hardware where each level is a partition, and each level fully covers the previous one (from any node you go through all levels using father/childrens, father/child are just one level away from each other. Actually, we support heterogeneous topologies where one level may not cover entirely the previous one, for instance if you have two different processors with different levels of caches. thanks that is good to know. In that case the upper level (let's assume it is a NODE) is still all at the same level, but the depth of the children of this might be different from depth-1? like this (I am skipping some levels, as just the structure is important): NODE 1 cache2 cache1 p0 cache2 cache1 p1 NODE 2 cache1 p2 cache1 p3 or is it even possible to have a node with children of a single node of different depth? this is supposing that you want to keep that a level has a single type (and given the api I suppose it is so). Fawzi
Re: [hwloc-devel] structure assumptions, duplication
Hello, Fawzi Mohamed, le Wed 30 Sep 2009 09:16:36 +0200, a écrit : > 1) a fully hierarchical representation of the machine/hardware where each > level > is a partition, and each level fully covers the previous one (from any node > you > go through all levels using father/childrens, father/child are just one level > away from each other. > This is basically what is there now. > > 2) outside the hierarchy 1 (but built using its object, probably the NUMA > nodes) there will be > 2.1) maybe the full connection graph > 2.2) a hierarchical view of it, like the lgroups, where the levels are not > necessarily a partition, and that could also refer not to the sublevel, but > directly to lower levels. Going up the hierarchy you get the next neighbors. Err, no, in our plans 2.2 was in 1) already, and levels are thus still partitions, but somehow arbitrary ones, according to heuristics based on the graph. Isn't that the case with lgroups ? (I haven't ever had access to a solaris numa machine) Samuel
Re: [hwloc-devel] structure assumptions, duplication
Fawzi Mohamed wrote: > 1) a fully hierarchical representation of the machine/hardware where > each level is a partition, and each level fully covers the previous > one (from any node you go through all levels using father/childrens, > father/child are just one level away from each other. Actually, we support heterogeneous topologies where one level may not cover entirely the previous one, for instance if you have two different processors with different levels of caches. Brice
Re: [hwloc-devel] structure assumptions, duplication
On 29-set-09, at 18:55, Fawzi Mohamed wrote: ok, I was thinking that maybe you did/would like to provide in the future something akin to what opensolaris does with locality groups http://opensolaris.org/os/community/performance/mpo_overview.pdf Yes, we intend to provide something similar. In fact what I "need" (or at least I think I need ;) is just the next neighbors, basically I go up the hierarchy, and look which new neighbors I have, so some hierarchy like the lgroups is close to what I need, and simpler to handle than the full graph. That's what future heuristics would build for you, yes. tha's great, I am really looking forward to it. So as summary, if I have understood correctly the current idea for the (future) structure of hwloc is: 1) a fully hierarchical representation of the machine/hardware where each level is a partition, and each level fully covers the previous one (from any node you go through all levels using father/childrens, father/child are just one level away from each other. This is basically what is there now. 2) outside the hierarchy 1 (but built using its object, probably the NUMA nodes) there will be 2.1) maybe the full connection graph 2.2) a hierarchical view of it, like the lgroups, where the levels are not necessarily a partition, and that could also refer not to the sublevel, but directly to lower levels. Going up the hierarchy you get the next neighbors. Separating 1 & 2 has the advantage that stronger assumption can be done on 1, simplifying it. ciao Fawzi
