Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] trouble using --mca mpi_yield_when_idle 1
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-12-12 08:37:14


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.guptill_at_[hidden] 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
> users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/users

-- 
Jeff Squyres
Cisco Systems