Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Remove all other paffinity components
From: George Bosilca (bosilca_at_[hidden])
Date: 2010-05-15 13:28:07


The problem here is that if we keep out component approach we cannot use the full power of the hwloc API, except if we provide exactly the same. Clearly not a suitable approach.

How about we use one of the "obscure" features of hwloc (hwloc_topology_set_xml: loads an XML file describing a topology), which will force hwloc to load the configuration from the file instead of gathering it from the current environment. I can see two benefits with this approach:
1. we can freely use all hwloc API to gain access to the most obscure architectural features (and we need then if we really want to harness the full potential of current architectures).
2. we can simulate any other architecture as soon as we have a description file. So the current test module will be somehow supported with even more extensive capabilities.

  george.

On May 15, 2010, at 12:19 , Jeff Squyres (jsquyres) wrote:

> Oh, I mis-read your mail. Yes, leaving the "test" component is a friendly amendment to this rfc.
>
> -jms
> Sent from my PDA. No type good.
>
> ----- Original Message -----
> From: devel-bounces_at_[hidden] <devel-bounces_at_[hidden]>
> To: Open MPI Developers <devel_at_[hidden]>
> Sent: Sat May 15 09:02:28 2010
> Subject: Re: [OMPI devel] RFC: Remove all other paffinity components
>
> Umm...I vote "no". I still need that "test" component to use when testing paffinity on machines that don't have all the required support (e.g., Mac).
>
> I don't have an opinion on the other components.
>
>
> On May 13, 2010, at 6:20 PM, Jeff Squyres wrote:
>
>> WHAT: Remove all non-hwloc paffinity components.
>>
>> WHY: The hwloc component supports all those systems.
>>
>> WHERE: opal/mca/paffinity/[^hwloc|base] directories
>>
>> WHEN: for 1.5.1
>>
>> TIMEOUT: Tuesday call, May 25 (yes, about 2 weeks from now -- let hwloc soak for a while...)
>>
>> -----------------------------------------------------------------------------
>>
>> MORE DETAILS:
>>
>> As you probably noticed, I have (finally) committed the "hwloc" paffinity component to the trunk and removed the "linux" (i.e., PLPA) paffinity component:
>>
>> https://svn.open-mpi.org/trac/ompi/changeset/23125
>> https://svn.open-mpi.org/trac/ompi/changeset/23126
>>
>> hwloc supports all systems that OMPI supports (and several that OMPI doesn't!) -- more specifically, it supports all the other systems that we have paffinity components for (darwin, linux, posix, solaris, windows). It can therefore fully replace all the other paffinity components.
>>
>> Indeed, the new hwloc's default priority is higher than all of the other current paffinity components, so over the next week or two, it'll be a good soak test to see if it is working properly. Once we get any kinks worked out, I propose removing all the other paffinity components and leaving only hwloc.
>>
>> That being said, we might as well leave the paffinity framework around, even if it only has one component left, simply on the argument that someday Open MPI may support a platform that hwloc does not.
>>
>> --
>> Jeff Squyres
>> jsquyres_at_[hidden]
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel