This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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:
>> 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. - http://homepage.mac.com/tmattox/
>> tmattox_at_[hidden] || timattox_at_[hidden]
>> I'm a bright... http://www.the-brights.net/
>> devel mailing list
> devel mailing list
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
tmattox_at_[hidden] || timattox_at_[hidden]
I'm a bright... http://www.the-brights.net/