LAM/MPI logo

LAM/MPI General User's Mailing List Archives

  |   Home   |   Download   |   Documentation   |   FAQ   |   all just in this list

From: Nathan Parker (nathanp_at_[hidden])
Date: 2002-09-18 08:51:27


Ahh, that explains the high CPU usage. I had assumed usysv's
"spin-locking" was merely locking to protect the consistency of data
structures, and not for waiting on queues.

I've recompiled my LAM installation to use TCP, and now the CPU
utilization on this one process is down to 2% (from 99%). Thanks for
your help.

As for the sysv version, shouldn't it be possible to wait on sockets and
semaphores at the same time, with the use of an additional thread? The
thread could block in a select() on all required sockets, and then set a
semaphore when a socket is ready for reading or writing.

 -- Nathan Parker

On Mon, 2002-09-16 at 15:17, Brian W. Barrett wrote:
> On 16 Sep 2002, Nathan Parker wrote:
>
> > I'm using MPI::Request::Waitany() in a while loop to collect data from 4
> > other nodes. After data from all nodes has been received, the data is
> > processed, and the Waitany() loop is restarted. I expected that most
> > this process will sit idle most of the time, waiting for data. Instead,
> > it appears to spin on the CPU (99% utilization). Is this a known bug?
> > If I do "mpirun -lamd," the problem goes away, but lamd then uses 15% of
> > the cpu.
>
> This is not a bug - it's a feature! Seriously, you might want to read the
> README file included with LAM distributions. The usysv transport "spins"
> fairly tightly when it is waiting for anything that might come from a
> local node (ie, over the shared memory channel). If you use the sysv
> transport, you should see significantly less CPU utilization in these
> cases.
>
> Note, of course, that LAM *has* to poll in ANY_SOURCE or Waitany cases
> when shared memory is in use. LAM has to look at a series of socket
> connections and a shared memory descriptor to check for available data.
> The only way to do this is polling. So, even with the sysv rpi, you are
> going to see a non-trivial amount of CPU utilization going to this
> polling. However, it should be much less than 99% of the CPU.
>
> Brian
>
> --
> Brian Barrett
> LAM/MPI developer and all around nice guy
> Have a LAM/MPI day: http://www.lam-mpi.org/
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/

_______________________________________________
This list is archived at http://www.lam-mpi.org/MailArchives/lam/