转载自chalou’s blog

问题描述

MPI的Collective同步操作中(如MPI_Recv,MPI_Win_fence),常会遇到一种情形,即大多数Rank已经完成通信,但由于MPI的同步语义,需要已经完成的Rank需要等待至同步点。但通过查看资源利用率,发现此时等待的进程已经处于100%的CPU资源利用率,即轮询忙等,而非进程Sleep。这种机制会造成以下不便:

  • 影响Communication和Computing的Overlap:常见的MPI通信应用不太出现这种需求,但是如果你的单个CPU上除了MPI通信外仍需要并发执行计算操作,程序的执行效率会受到影响。

  • 影响操作系统执行效率:操作系统面对应用带来的高负荷CPU利用率时,会对系统必要的管理造成额外的时间开销。

  • 浪费能源:CPU轮询除了会造成CPU功耗过载,也会导致系统的节电管理失效。

调研结果

根据Google搜索,查到以下讨论:

根据以上内容可以总结出以下结论:

  1. 从7年前,开发者们就意识到nemesis通信设备存在此问题,至今仍未解决(他们还是不感兴趣)。但是开发者门称,nemesis就是为了提高通信效率而故意采用的轮询机制。

  2. 除了Communication和Computing的Overlap需求,当MPI process数大于当前CPU的核心数(即oversubscription),也会出现明显的性能下降。

  3. 根据开发者们的测试,针对计算量较大的应用场景,nemesis不比sock设备快,甚至会在过载的情形下远慢于sock设备。

解决方案

如果你需要并发执行较大计算量的应用,或进行过载Process的调度,又不需要BLCR之类的检查点技术,让mpich使用sock设备通信,因为sock设备是由系统内核提供的event-based polling,可以在等待时使进程Blocking。

方法是在configure时添加参数:

--with-device=ch3:sock

然后再进行make install。

问题解决。

附:自己的编译选项

1
2
3
./configure --prefix=$HOME/mpich-sock --enable-fortran=all  --enable-fast=all,O3 --with-device=ch3:sock CC=icc CXX=icc FC=ifort F77=ifort 

make -j 12&&make install