See https://github.com/jeffhammond/mpich/commit/1f4f6b1ecef8c6ea727ea671cec9a928.... Please note that this is a hack not a proper implementation. It should use whatever internal affinity API MPICH uses. It won't work on Mac because I don't think Mac OS supports affinity. I'm very curious to know your results. I never got around to experimenting with this implementation as I had hoped. Best, Jeff On Tue, Oct 22, 2013 at 11:58 AM, Jeff Hammond <[email protected]> wrote:

I already implemented this. Let me do a merge with the latest trunk and then put it as a branch on https://github.com/jeffhammond/mpich. You may need to assign an comm thread in order to observe passive progress on this operation :-)

I seriously doubt the OS will migrate all the busy-polling progress threads to the same core. Pinning them manually is going to be required.

Jeff

On Tue, Oct 22, 2013 at 8:01 AM, Pavan Balaji <[email protected]> wrote:

...

Tareq,

On Oct 22, 2013, at 7:02 AM, Tareq Malas wrote:

...

I am looking for a relatively simple way to control the affinity mapping of the MPICH progress thread and the other threads of my application. In particular, I am using a cluster that has dual 8-core Intel Sandy Bridge sockets per node. I would like to assign the progress thread to a singe core and use the other cores to run my application. Is there a way to pin or detect which core is assigned to the progress thread? I am using MVAPICH2 version 1.9a2 built with icc version 13.1.0 (gcc version 4.4.7 compatibility). I am already using MPICH_ASYNC_PROGRESS variable, but I am not sure how can I combine this with thread affinity mapping library.

Hydra provides a way to bind all threads of the process to a set of cores (e.g., you can assign all cores of the socket to all threads of your process), but no way to specifically bind each thread to a particular core. You'll need to do this assignment from inside your application.

I understand that this is inconvenient for the MPICH progress thread, since that's within MPI, and that should be fixed within MPICH. We'll do that. But in reality, it's best to leave that thread not bound to a particular core, IMO.

-- Pavan

-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

-- Jeff Hammond [email protected]

-- Jeff Hammond [email protected]