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.
http://developer.apple.com/releasenotes/Performance/RN-AffinityAPI/
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/
tmat...@gmail.com || timat...@open-mpi.org
I'm a bright... http://www.the-brights.net/
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
