WHAT: hwloc is currently embedded in opal/mca/paffinity/hwloc/hwloc -- move it 
to be a first class citizen in opal/hwloc.

WHY: Let other portions of the OPAL, ORTE, and OMPI code bases use hwloc 
services (remember that hwloc provides detailed topology information, not just 
processor binding).

WHERE: Move opal/mca/paffinity/hwloc/hwloc to opal/hwloc, and adjust associated 
configury

WHEN: For v1.5.1

TIMEOUT: Tuesday call, May 25

-----------------------------------------------------------------------------

MORE DETAILS:

The hwloc code base is *much* more powerful and useful than PLPA -- it provides 
a wealth of information that PLPA did not.  Specifically: hwloc provides data 
structures detailing the internal topology of a server.  You can see cache line 
sizes, NUMA layouts, sockets, cores, hardware threads, ...etc.

This information should be available to the entire OMPI code base -- not just 
locked up in a paffinity component.  Putting hwloc up in opal/hwloc makes it 
available everywhere.  Developers can just call hwloc_<foo>, and OMPI's build 
system will automatically do all the right symbol-shifting if the embedded 
hwloc is used in OMPI (and not symbol-shift if an external hwloc is used, 
obviously).  It's magically delicious!

One immediate use that I'd like to see is to have the openib BTL use hwloc's 
ibv functionality to find "nearby" HCAs (right now, you can only do this with 
rankfiles).

I can foresee other components using cache line size information to help tune 
performance (e.g., sm btl and sm coll...?).

To be clear: there will still be an hwloc paffinity component.  It just won't 
embed its own copy of hwloc anymore.  It'll use the hwloc services provided by 
the OMPI build system, just like the rest of the OPAL / ORTE / OMPI code bases.

There will also be an option to compile hwloc out altogether -- some stubs will 
be left that return ERR_NOT_SUPPORTED, or somesuch (details TBD).  The reason 
for this is that there are some systems where processor affinity and NUMA 
information aren't relevant (e.g., embedded systems).  Memory footprint is key 
in such systems; hwloc would simply take up valuable RAM.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/


Reply via email to