FWIW, Open MPI does have on its long-term roadmap to have "blocking"
progress -- meaning that it'll (probably) spin aggressively for a
while and if nothing "interesting" is happening, it'll go into a
blocking mode and let the process block in some kind of OS call.
Although we have some interesting ideas on how to do this, it's not
entirely clear when we'll get this done. There's been a few requests
for this kind of feature before, but not a huge demand. This is
probably because most users running MPI jobs tend to devote the entire
core/CPU/server to the MPI job and don't try to run other jobs
concurrently on the same resources.
On Dec 8, 2008, at 2:14 PM, Eugene Loh wrote:
douglas.gupt...@dal.ca wrote:
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
second.
It isn't a binary situation. The first extreme you mention is
"consume a lot of resources and spring into action as soon as there
is work to do." The second extreme you mention is "don't use any
extra resources, but take a loooong time to wake up once there is
something to do". There are a bunch of alternatives in-between.
E.g., "don't use as much resource and wake up kind of fast when
there is something to do."
OMPI's yield behavior is such an in-between alternative.
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.
I could imagine another alternative. Construct a wrapper function
that intercepts MPI_Recv and turn it into something like
PMPI_Irecv
while ( ! done ) {
nanosleep(short);
PMPI_Test(&done);
}
I don't know how useful this would be for your particular case.
Douglas Guptill wrote:
On Mon, Dec 08, 2008 at 08:56:59PM +1100, Terry Frankcombe wrote:
As Eugene said: Why are you desperate for an idle CPU?
So I can run another job. :-)
But in that case, be careful what you measure. If a process is
performing a lot of yields, it may be running up the CPU
utilization, but a new process that you submit may still get a lot
of time.
I think of an automobile-traffic analogy. Let's say you have a
bunch of cars that will all yield to an ambulance. If there is no
ambulance on the road, it looks like there is a lot of traffic and a
vehicle will not be able to go fast. But, if you put the ambulance
on the road, all those vehicles yield and the ambulance goes pretty
fast -- on a road that just minutes ago looked congested.
In both cases (OMPI yield and the traffic analogy), things would be
better if there were no traffic whatsoever. But, if processes are
yielding, then the appearance of congestion is not a reliable
indication of how well an added process will perform.
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
Cisco Systems
