Jeff Squyres, le Mon 11 Jan 2010 10:12:00 -0500, a écrit :
> Been mulling this for a few days; here's my thoughts...
Thanks!
> Are you thinking of adding bandwidth attributes?
When the information is available through some way (be it by hand), yes.
> Or are you thinking of adding weighting between objects in the hierarchy? Or
> ...?
I'd tend to think that this would be an upper layer that applications
would compute themselves, according to their needs.
> More generally -- some objects can be bound to, some cannot.
>
> How does this kind of thing extend to, say, co-processors (such as
> accelerators, FPGAs, GPGPUs, etc.)?
I once thought about adding gpuset, maybe, but since the kinds of
objects will probably vary a lot, maybe it's better to not try to be
smart and let layers above handle it, only possibly provide for each
kind the OS number (e.g. CUDA device number).
> > - This also means there can't be "global" cpusets like the recently
> > added hwloc_topology_get_{topology,complete,online,allowed}_cpuset
> > functions (not released yet). These can just be moved to the hwloc_obj
> > structure, thus being available for each object, which could actually be
> > helpful btw.
>
> I'm not sure I follow -- you say that we can't have "global" cpusets anymore
> (which I grok), but then you say that we can move them to the hwloc_obj
> struct. Isn't that the top-level struct?
No, the hwloc_obj struct is the type of the nodes of the tree. A cpuset
makes sense at that place, and possibly also upper in the tree, until
you get up to a machine level, the last level where cpuset != NULL.
After that you have several machines and cpusets don't make sense any
more.
> > - Helpers that take cpuset parameters of course don't make sense any more
> > when applied to networked topologies. But it probably doesn't make
> > sense for the caller to call them in the first place, and the caller
> > knows it since it's the caller that has first called the combining
> > operation or loaded an XML file resulting from it.
>
> Agreed. Perhaps we should have a general query function that can return
> whether a given object can be bound to or not (e.g., for generic
> tree-traversal kinds of functionality)...?
Well, to be "bound to" here would mean for a thread, i.e. to be bound
to a CPU set. So testing for cpuset != NULL should be enough. As said
above, I'm not sure we necessarily want to extend that notion since
the various kinds of "binding something to" becomes numerous. In CUDA
for instance, it doesn't make sense to bind something to some GPU,
you rather need a GPU number on which you want to start a particular
computation kernel.
> 1. How about defining a small set of generic operations based on what you
> described above? E.g.:
Sure
> - copy, remove, insert
Agreed, and can be done later, I think keeping that in mind is
sufficient for now.
> > The plan I see is that for 1.0 we only check that catenating .XML files
> > by hand to build misc levels representing network layers does indeed
> > work, which should mean that actual combining functions etc. should be
> > possible to implement later.
>
> FWIW, I'd prefer to see the combining/etc. functions ASAP -- we could
> definitely use such things in Open MPI...
Mmm, doing it in the API is not so trivial, for 1.0 I'd rather just
provide a small xml combiner (just a matter of tail/head/cat), which may
be enough for a start. But if you need it at the API level, we can add
it to the 1.0 milestone.
Samuel
