So, to ensure I understand, you are proposing that we completely eliminate the paffinity framework and commit to hwloc in its place?
I'm not necessarily opposed to the idea, so long as "test" can be supported as you describe. However, I do have a concern about becoming so strongly dependent on hwloc - a software package we do not control, written by non-members of our community with whom we have little interaction. The event lib is one example of that model, and it hasn't work out that great. I guess we always have the option of re-installing the paffinity framework...but that might not be so easy to do. So if we do what you propose, who would go in and revamp everywhere that currently calls paffinity? (ie, don't look at me). Why not just revamp the paffinity framework API and retain an easy ability to revert if, for example, INRIA stops being funded for hwloc and drops support for it? On May 15, 2010, at 11:28 AM, George Bosilca wrote: > 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-boun...@open-mpi.org <devel-boun...@open-mpi.org> >> To: Open MPI Developers <de...@open-mpi.org> >> 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 >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
