Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Thread/Process affinity for Mac OS X
From: Tim Mattox (timattox_at_[hidden])
Date: 2008-12-12 11:47:29

Hi Ralph,
The Mac OS X affinity stuff doesn't work like Linux, etc.
The document I pointed to is sparse in details, but basically
they didn't leave a way for unrelated processes to affect
how they are scheduled relative to each other. Only
processes/threads that have a fork/thread-spawn ancestor
can cooperate/coordinate on who runs where.

They have this "affinity namespace" thing that would need to be inherited
from a common ancestor, so that then each rank could specify
within that namespace which other threads it should/should-not
share L2 cache's with. Its funky, and not at all like how we
currently do affinity. That was why I said this would
be "quite a bit of work". It is probably not worth the effort,
unless Apple wanted to contribute directly.

On Fri, Dec 12, 2008 at 11:29 AM, Ralph Castain <rhc_at_[hidden]> wrote:
> But we don't want the child to inherit affinity from the orted anyway, so I
> don't see why the exec call is an issue for us. The MPI proc sets its own
> affinity during MPI_Init using the paffinity framework, so it looks to me
> like the only thing missing is the correct set_affinity code in the darwin
> paffinity module.
> On Dec 12, 2008, at 9:21 AM, Tim Mattox wrote:
>> Hello,
>> I just ran across this document from Apple that describes
>> the Thread affinity scheme that was added in Leopard.
>> In its current form, and how orteds start the MPI ranks with exec,
>> we can't use this, AFAIK. However, if someone cares, there
>> might be a path for doing MPI process affinity on Mac OS X
>> with quite a bit of work. Let me know if you have the
>> time & interest, and I can explain my idea on how to do it.
>> For the curious, here is the key text extracted from that document:
>> "Generally, the affinity tag namespace is private to one task
>> (process). However, a child process forked after its parent has made a
>> THREAD_AFFINITY_POLICY call will share the affinity namespace of the
>> parent process. This enables a family of forked processes to share an
>> affinity namespace despite comprising separate tasks. Moreover, the
>> forked child inherits the affinity tag of its parent. Hence, a parent
>> can seed a number of child processes within an arbitrary organization
>> of shared affinity sets. Note: affinity namespace inheritance is
>> destroyed by the exec(3) system call, however."
>> It's that last sentence about exec(3) that makes things (very) difficult
>> for us.
>> --
>> Tim Mattox, Ph.D. -
>> tmattox_at_[hidden] || timattox_at_[hidden]
>> I'm a bright...
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Tim Mattox, Ph.D. -
 tmattox_at_[hidden] || timattox_at_[hidden]
    I'm a bright...