Fawzi Mohamed, le Tue 29 Sep 2009 16:39:47 +0200, a écrit :
> Maybe I worry too much, but with machines with 1'000 of processor
> coming, and maybe wanting local restricted copies to know the topology
> of the whole machine (to communicate with others) I worry also about
> few pointers here an there.
Actually the size of all the pointers is not so much compared to the
size of the cpuset (by default 1024/8 = 128 bytes, worth 16 pointers).
> 2) assumption on the structure
> Also a ring like topology cannot be cleanly represented with a
> partition if one wants to have objects for groups with uniform latency.
Our plan was to not only provide a hierarcical view but also the precise
graph. For instance, that means that for an Altix machine with a
2D-mesh of 3*4 NUMA nodes, the hierarchy would be system containing
12 nodes, themselves containing a socket etc. And the fact that the
12 nodes are organized as a 2D-mesh would be expressed by a graph
structure, independently of the hierarchy.
> At least the Misc object would seem to not fit in this clean
> hierarchical picture.
The Misc object is meant to not be interpreted any other way than
just grouping, so it is still hierarchical. For instance AIX provides
a hierarchical view of the machine, and for some levels I don't
know what they correspond to (new levels, not documented or unclear
documentation), but hwloc still expose them. Windows has a particular
notion of processor groups due to bad design and it's a good idea to
take that into account.
The idea is that some programmers will only want to cope with a
hierarchical machine, while others will want to fine-tune according to
the precise topology (much harder, not polynomial at least). And thus we
should provide both. For the first kind of programmers, to tackle the
3*4 2D-mesh case above, we could provide a flag "make it hierarchical",
which would heuristically group nodes recursively according to locality.
For now we only do such grouping from the NUMA distances when there are
clear NUMA subgroups.
> So I wanted to know how you cope with those things, and also if
> something will probably change in the future, as some assumptions will
> inevitably creep in my code... and I would prefer to make the good
> ones :)
We should probably (agree on and) state what we want to always provide