[转载]MPI的同步阻塞问题
文章目录
【注意】最后更新于 June 12, 2016，文中内容可能已过时，请谨慎使用。
问题描述
MPI的Collective同步操作中（如MPI_Recv,MPI_Win_fence），常会遇到一种情形，即大多数Rank已经完成通信，但由于MPI的同步语义,需要已经完成的Rank需要等待至同步点。但通过查看资源利用率，发现此时等待的进程已经处于100%的CPU资源利用率，即轮询忙等，而非进程Sleep。这种机制会造成以下不便：
影响Communication和Computing的Overlap：常见的MPI通信应用不太出现这种需求，但是如果你的单个CPU上除了MPI通信外仍需要并发执行计算操作，程序的执行效率会受到影响。
影响操作系统执行效率：操作系统面对应用带来的高负荷CPU利用率时，会对系统必要的管理造成额外的时间开销。
浪费能源：CPU轮询除了会造成CPU功耗过载，也会导致系统的节电管理失效。
调研结果
根据Google搜索，查到以下讨论：
根据以上内容可以总结出以下结论：
从7年前，开发者们就意识到nemesis通信设备存在此问题，至今仍未解决（他们还是不感兴趣）。但是开发者门称，nemesis就是为了提高通信效率而故意采用的轮询机制。
除了Communication和Computing的Overlap需求，当MPI process数大于当前CPU的核心数（即oversubscription）,也会出现明显的性能下降。
根据开发者们的测试，针对计算量较大的应用场景，nemesis不比sock设备快，甚至会在过载的情形下远慢于sock设备。
解决方案
如果你需要并发执行较大计算量的应用，或进行过载Process的调度，又不需要BLCR之类的检查点技术，让mpich使用sock设备通信，因为sock设备是由系统内核提供的event-based polling，可以在等待时使进程Blocking。
方法是在configure时添加参数：
--with-device=ch3:sock
然后再进行make install。
问题解决。
附：自己的编译选项
|
|
文章作者 chalou
上次更新 2016-06-12