[转载]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