Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] [hwloc-svn] svn:hwloc r3046
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2011-01-18 14:00:17


On Jan 12, 2011, at 10:10 AM, Samuel Thibault wrote:

> This is not what I meant: hwloc_alloc_membind_policy's purpose is only
> to allocate bound memory. It happens that hwloc_alloc_membind_policy
> _may_ change the process policy in order to be able to bind memory
> at all (when the underlying OS does not have a directed allocation
> primitive), but that's not necessary. If hwloc can simply call a
> directed allocation primitive, it will do it. If the OS doesn't support
> binding at all, then hwloc will just allocate memory.

How's this?

 * Setting this policy will cause the OS to try to bind a new memory
 * allocation to the specified set. As a side effect, some operating
 * systems may change the current memory binding policy; others may
 * simply ignore the policy (i.e., not bind the new memory allocation
 * at all). Note that since HWLOC_MEMBIND_STRICT was not specified,
 * failures to bind will not be reported -- generally, only memory
 * allocation failures will be reported (e.g., even a plain malloc()
 * would have failed with ENOMEM).

>> + HWLOC_MEMBIND_INTERLEAVE = 3, /**< \brief Allocate memory on
>
> This is not really correct: if the threads were splitting the memory
> amongst themselves, FIRSTTOUCH should be used instead, to migrate pages
> close to where they are referenced from. I have rephrased that

What's a good simple example scenario when it would be good to use INTERLEAVE, then?

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