<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">if your process run more than 1 threads, you are likely to see performance problem too.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">tan<BR><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Darius Buntinas <buntinas@mcs.anl.gov><BR>To: Nate Crawford <nathan.crawford@chemie.uni-karlsruhe.de><BR>Cc: mpich-discuss <mpich-discuss@mcs.anl.gov><BR>Sent: Friday, February 23, 2007 6:44:02 AM<BR>Subject: Re: [MPICH] Idle processes at 100% load with ch3:ssm and nemesis, but not ch3:sock<BR><BR>
<DIV>Nemesis does busy waiting by design. By polling for messages in this <BR>fashion we can achive the best communication performance. If we were to <BR>use blocking synchronization operations (which would not use the cpu) this <BR>would incur a large overhead, especially for shared-memory communication <BR>where it could more than double the one-way latency of small messages.<BR><BR>That said, we do intend to provide an optional blocking mode for <BR>situations where the processors are oversubscribed (i.e., more than one <BR>process per processor).<BR><BR>Darius<BR><BR><BR>On Fri, 23 Feb 2007, Nate Crawford wrote:<BR><BR>> Hi All,<BR>><BR>> I am having a significant problem using shared memory for intra-node<BR>> communications with MPICH2-1.0.5p3 (and some earlier versions). Some of<BR>> our parallel programs are based on a master/slave arrangement where the<BR>> master coordinates the slaves, but does no real work. When
using sockets<BR>> for intra-node message passing, things work as intended: the master is<BR>> nearly always idle, and all but one of the slaves are idle during the<BR>> sequential parts. With ch3:ssm or nemesis, all processes are always<BR>> using 100% CPU, even when they are only waiting for the signal to<BR>> proceed.<BR>><BR>> I suspect that the waiting processes are not using the best method for<BR>> receiving messages, but do not know what to look for. Is this known<BR>> behavior? I compiled MPICH2 with gcc 4.1.2 and pgf90 6.2-2 on SuSE 10.2<BR>> (x86-64).<BR>><BR>> Thanks,<BR>> Nate<BR>><BR>></DIV></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1>8:00? 8:25? 8:40? <a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news"> Find a flick</a> in no time<br> with the<a href="
http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news">Yahoo! Search movie showtime shortcut.</a></body></html>