On Sun, Dec 07, 2008 at 11:15:21PM -0800, Eugene Loh wrote:
> Douglas Guptill wrote:
> >I am using openmpi-1.2.8 to run a 2 processor job on an Intel
> >Quad-core cpu. Opsys is Debian etch. I am reaonably sure that, most
> >of the time, one process is waiting for results from the other. The
> >code is fortran 90, and uses mpi_send and mpi_recv. Yet
> >"gnome-system-monitor" shows 2 cpus at 100%.
> >So I read, and re-read, the FAQs, and found the mpi_yield_when_idle
> >flag, and tried it:
> >mpirun --host localhost,localhost,localhost,localhost --mca btl sm,self
> >--mca mpi_yield_when_idle 1 --byslot -np 2
> >And still get, for each run, two cpus are at 100%.
> >My goal is to get the system to a minimum usage state, where only one
> >cpu is being used, if one process is waiting for results from the
> >Can anyone suggest if this is possible, and if so, how?
> I'm no expert on this, but I've played with the same problem. I think I
> did this on Solaris, but perhaps the behavior is the same on other OSes.
> One issue is that "yield" might mean "yield if there is someone else
> ready to run". Like a traffic sign: if someone else is there, you
> yield. If no one else is there, there's no way to tell that someone is
> Next, even if someone else is trying to run, "yield" doesn't give give
> up the CPU 100%. It's still rather pesky.
> So, one question is whether you really want to have an idle CPU. Do
> you, or do you simply want another process, if there is one, to be able
> to run?
> Not a real answer to your question, but hopefully this helps.
It does. I think you have raised an excellent question: yield to who?
I can think of 3 classes of process:
1. other processes created by the same "mpirun"
2. other processes created by a different "mpirun"
3. other processes.
Classes 2 and 3 seem to be out of the range of possibility under the
circumstances, so we are left with class 1. In my case, there are
only two processes:
one is computing,
the other is in "mpi_recv".
Proceeding from that, it seems that "mpi_recv" is implemented as
"poll forever until the message comes"
and NOT as
"sleep until the message comes"
I had assumed, until now, that mpi_recv would be implemented as the
If "mpi_recv" is implemented as "poll forever", openmpi (or any MPI
with the same implementation) would seem to be unsuitable for my
application, since the application is using two cpus, but only getting
real work out of one.
Research Assistant, LSC 4640 email: douglas.guptill_at_[hidden]
Oceanography Department fax: 902-494-3877
Halifax, NS, B3H 4J1, Canada