Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Remove all other paffinity components
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2010-05-17 20:25:51


On May 17, 2010, at 7:59 PM, Barrett, Brian W wrote:

> HWLOC could be extended to support Red Storm, probably, but we don't have the need or time to do such an implementation.

Fair enough.

> 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...

We need a mechanism to have hwloc *not* be there, particularly for embedded environments -- where hwloc would add no value. This is apparently just like Red Storm, but even worse because we need to keep the memory footprint down as much as possible (libhwloc.so.0.0 on linux is 104KB -- libhwloc.a is 139KB -- both are big numbers when you only have a few MB of usable RAM). So even leaving stubs doesn't seem like a good idea -- they'll take up space, too. And the hwloc API is fairly large -- maintaining stubs for all the API functions could be a daunting task.

I think embedding is the main reason I can't think of any better idea than #if OPAL_HAVE_HWLOC.

I anticipate that hwloc usage would be fairly localized in the OMPI code base:

int btl_sm_setup_stuff(...)
{
#if OPAL_HAVE_HWLOC
     ...do interesting hwloc things...
     ...setup stuff on btl_sm_component...
     btl_sm_component.have_hwloc = 1;
#else
     btl_sm_component.have_hwloc = 0;
#endif
}

int btl_sm_other_stuff(...)
{
    if (btl_sm_component.have_hwloc) {
        ...use the hwloc info...
    }
}

But I'm certainly open to other ideas -- got any?

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/