HWLOC could be extended to support Red Storm, probably, but we don't have the need or time to do such an implementation. Given that, I'm not really picky about what the method of not breaking an existing supported platform is, but I think having HAVE_HWLOC defines everywhere is a bad idea...
Brian On May 17, 2010, at 7:51 PM, Jeff Squyres (jsquyres) wrote: > Can hwloc be extended to support redstorm? I.e., does your os export the > topology info and/or support process binding? > > Hwloc *is* an open mpi sub project, after all... > > Other than extending hwloc, I don't know what else to do besides #if > OPAL_HAVE_HWLOC - the hwloc api is kinda big. In this way, hwloc is just like > any other library that ompi uses. It just happens to be in the tree because > a) its usedful to us and b) it isn't widely already-installed. > > -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: Mon May 17 17:36:58 2010 > Subject: Re: [OMPI devel] RFC: Remove all other paffinity components > > I'd prefer we not commit something in opal/hwloc until we have a plan for > supporting platforms without hwloc support (ie, Red Storm). I have no > objection to your original RFC, but I had the impression at the time that you > had a plan in place for non-hwloc supported platforms. > > Brian > > On May 17, 2010, at 5:26 PM, Jeff Squyres wrote: > >> On May 15, 2010, at 4:39 PM, Ralph Castain wrote: >> >>> So, to ensure I understand, you are proposing that we completely eliminate >>> the paffinity framework and commit to hwloc in its place? >> >> I think there's 2 issues here: >> >> - topology information >> - binding >> >> hwloc supports both. paffinity mainly supports binding; it also supports >> some minor socket/core mapping information stuff, but mainly as a means to >> support binding better. hwloc's topology information is far more complete >> than paffinity's. >> >> How about this? (and this is very half-baked) >> >> - commit hwloc to opal/hwloc; the entire tree can call it >> - it's still TBD how to compile this out (e.g., for embedded environments) >> - it *may* need something like #if OPAL_HAVE_HWLOC >> - split paffinity into two frameworks (because some OS's support one and not >> the other): >> - binding: just for getting and setting processor affinity >> - hwmap: just for mapping (board, socket, core, hwthread) <--> OS processor >> ID >> >> In this way, if hwloc ever dies, we can still have OS-specific plugins for >> these two things, and the #if OPAL_HAVE_HWLOC will be 0. >> >> hwloc provides a very rich API for traversing the topology information; I >> don't think the main OPAL/ORTE/OMPI code base necessarily needs all of that >> functionality for the general case -- i.e., the binding/hwmap information >> (e.g., just want to bind a process to (board 1, socket 3, core 2, hwthread >> 1)). >> >> Anything that needs the detailed hwloc information (e.g., tuning the sm btl >> based on cache sizes reported by hwloc) can use #if OPAL_HAVE_HWLOC to >> protect itself. >> >> -- >> 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 >> > > -- > Brian W. Barrett > Dept. 1423: Scalable System Software > Sandia National Laboratories > > > > > > _______________________________________________ > 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 > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories
