To follow up on this RFC...
This RFC also got discussed on the weekly call (and in several other discussions). Again, no one seemed to hate it. That being said, hwloc still needs a bit more soak time; I just committed the 32 bit fix the other day.
So this one will happen eventually (i.e., #1, below -- #2 is the other RFC). It'll probably be off in an hg branch at first, and then I'll bring the results to the community before bringing it back into the trunk.
On May 18, 2010, at 8:50 AM, Jeff Squyres wrote:
> On May 18, 2010, at 8:31 AM, Terry Dontje wrote:
>> The above sounds like you are replacing the whole paffinity framework with hwloc. Is that true? Or is the hwloc accessors you are talking about non-paffinity related?
> Good point; these have all gotten muddled in the email chain. Let me re-state everything in one place in an attempt to be clear:
> 1. 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
> --> Note that hwmap will be an expansion of the current paffinity capabilities
> 2. Add hwloc to opal
> - Commit the hwloc tree to opal/util/hwloc (or somesuch)
> - Have the ability to configure hwloc out (e.g., for embedded environments)
> - Add a dozen or two hwloc wrappers in opal/util/hwloc.c|h
> - The rest of the OPAL/ORTE/OMPI trees *only call these wrapper functions* -- they do not call hwloc directly
> - These wrappers will call the back-end hwloc functions or return OPAL_ERR_NOT_SUPPORTED (or somesuch) if hwloc is not available
> Jeff Squyres
> For corporate legal information go to:
For corporate legal information go to: