OK, thank you.<br><br><div class="gmail_quote">On Tue, Oct 16, 2012 at 2:22 PM, Darius Buntinas <span dir="ltr"><<a href="mailto:buntinas@mcs.anl.gov" target="_blank">buntinas@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You can control it with --with-shared-memory[=auto|sysv|mmap].  You can check which is being used by looking at the configure output (look for "Using a memory-mapped file for shared memory" or "Using SYSV shared memory").<br>

<span class="HOEnZb"><font color="#888888"><br>
-d<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Oct 16, 2012, at 3:11 PM, Shigang Li wrote:<br>
<br>
> Hi,Darius,<br>
> Thank you and this really makes sense. I still have one question. Is it possible for a MPICH programmer to know which configuration is using, e.g. posix shared memory,  sys V shared memory or disabled?<br>
><br>
> Best Regards,<br>
> Shigang.<br>
><br>
> On Mon, Oct 15, 2012 at 10:18 AM, Darius Buntinas <<a href="mailto:buntinas@mcs.anl.gov">buntinas@mcs.anl.gov</a>> wrote:<br>
><br>
> MPICH configure will try to use posix shared memory (i.e., mmapping a file), and if that fails it will try to use sysv shared memory (i.e., shmat).  If that fails, I think configure aborts (but it may just disable shared memory, I'm not sure).  Sysv shared memory typically has tight limits on the amount of shared memory that can be allocated per process and per node, so you don't really want to use that.<br>

><br>
> At init time, the processes query the process manager for the topology (i.e., which processes are on which nodes), and based on that decide which pairs of processes should communicate using shared memory and which should use the network.<br>

><br>
> Currently collectives are implemented using point-to-point messages, so some messages will go over shared memory and some over the network.  The communication patterns used by the collectives are optimized to take the topology into account.  MPICH does have an interface to allow implementors to override the default collective algorithms, such as using shared memory, but we haven't done this yet.<br>

><br>
> -d<br>
><br>
><br>
> On Oct 14, 2012, at 8:31 PM, Shigang Li wrote:<br>
><br>
> > Dear Sir or Madam,<br>
> ><br>
> > I'm a student from UIUC, and have some questions about communication optimizations on shared memory in state-of-art mpich2.<br>
> ><br>
> > 1) When configure mpich2, does it support shared memory optimization in default? If so, can it select the communication pattern automatically according to hardware architecture? For example in a SMPs cluster, using shared memory optimization within a node and using socket cross nodes?<br>

> ><br>
> > 2) What about collective communication on shared memory? Is it implemented on top of the optimized point to point communication or use other mechanisms?<br>
> ><br>
> > Best Regards,<br>
> > Shigang.<br>
><br>
><br>
<br>
</div></div></blockquote></div><br>