Because of how MPICH2 is implemented, there's one test that we could use to measure the impact of the global lock.

Have t threads send to/receive from MPI_PROC_NULL .  The test for this destination is, IIRC, deep in the ch3 code.  This will avoid *all* of the communication device while measuring most of the MPICH2 stack.

Bill

On Jan 30, 2008, at 3:03 PM, Rajeev Thakur wrote:

I would say threading overhead as might be seen by an application. The tests
in www.mcs.anl.gov/~thakur/thread-tests also try to measure that. I will
point Sameer at those.

Rajeev

-----Original Message-----
From: owner-mpich2-core@mcs.anl.gov 
[mailto:owner-mpich2-core@mcs.anl.gov] On Behalf Of Pavan Balaji
Sent: Wednesday, January 30, 2008 2:57 PM
To: mpich2-core@mcs.anl.gov
Subject: Re: [mpich2-core] MPICH2 Threading Overhead


Yeah, I misunderstood the code. Darius pointed it out too. 
However, it 
again comes back to what exactly we want to measure -- threading 
overhead in MPICH2 or threading overhead in the overall communication 
and networking stack?

  -- Pavan

On 01/30/2008 01:57 PM, Rajeev Thakur wrote:
Well the original code IBM sent does not have this 1 
process limitation. See
attached. The threads of a process communicate with the 
threads of another
process. I think that is a better test. Why did we change it?

Rajeev


-----Original Message-----
[mailto:owner-mpich2-core@mcs.anl.gov] On Behalf Of Darius Buntinas
Sent: Wednesday, January 30, 2008 1:07 PM
Subject: Re: [mpich2-core] MPICH2 Threading Overhead


I just want to check what the benchmark should do.

My understanding from the conference calls and Sameer's 
slides is that 
they're interested in the case where multiple threads of a 
process are 
sending/receiving to/from different processes.  This allows 
the process 
to use multiple DMAs concurrently.

Right now, we've been testing the case where one process is 
sending/receiving with itself.  So moving the locks around VCs may 
decrease the size of the CS, but will still serialize.

So what's the test we want to run?

   I imagine something like P processes each with P-1 threads 
where each 
thread is communicating with a different process.  But 
then we need a 
machine with P(P-1) cores.

   On the 8-core nodes we have, we can run 3 processes 
with 2 threads 
each.  But I think we need more threads to really stress things.

It seems that what we can see from the one or two processes 
is the just 
the effect of the size of the CS.

Comments?

-d



-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji




William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign