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
