[mpich-discuss] less busy polling with Nemesis

[Bland, Wesley B.]

Hi Daniel,

We are actually working on this at the moment. There is a ticket to describe the status of the work: https://trac.mpich.org/projects/mpich/ticket/79. Despite the appearance, there is work planned here. Currently, this is slated for MPICH 3.3 in 2016. It’s possible that it could show up earlier in the nightlies, but there’s no guarantees.

Thanks,
Wesley

On Dec 9, 2014, at 1:17 PM, Daniel Ibanez <dan.a.ibanez at gmail.com<mailto:dan.a.ibanez at gmail.com>> wrote:

Hello,

I have noticed that simple things like MPI_Barrier
will raise my CPU usage to near 100% while waiting,
and read in past emails and the FAQ that this is due
to busy polling in Nemesis.
As far as I can tell, the one solution usually offered
to reduce this CPU usage
is reconfiguring with sockets instead of Nemesis.
I would also like to use the MPI_THREAD_MULTIPLE
feature, but I read that the socket channels
don't support it, and it would be annoying to
have to recompile MPICH to get one benefit or the other.

I was just wondering if recent advancements invalidated
some of the above and officially ask what the options are
for reducing the CPU usage of MPICH during barriers.

Thank you,
_______________________________________________
discuss mailing list     discuss at mpich.org<mailto:discuss at mpich.org>
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20141209/b350872d/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss