在 MPI 并行程序中处理 I/O 的一种典型方式是要么将所有数据读取到单个节点并相应地分派到其他节点，要么将所有数据发送到单个节点并从该节点写入。
我目前使用阻塞通信。
由于“主”进程一次只能与一个节点通信，因此大多数节点都陷入了阻塞通信步骤：它们在等待主节点发送/接收时基本上“什么都不做”。这是完全可以理解的。
但是，当我使用“top”查看 CPU 使用率时，程序的所有副本都有完整的 99 - 100% 的 CPU 使用率。这意味着（与我最初的猜测相反）等待通信的另一端不是占用相当少 CPU 的“空闲任务”，而是“忙碌”任务。
如何减少这些“等待”节点的 CPU 使用率？非阻塞通信在这里相关吗？
感谢您的任何回答，
这取决于您用于 MPI 的通信设置。在阻塞通信中，MPI 有三种等待模式。
积极的忙等待。这是一种默认模式。至少，当 Open MPI 认为它完全订阅或订阅不足（进程数<=处理器数）时，它会使用它。在这种模式下，进程永远不会自愿放弃处理器给其他进程。OpenMPI 在紧密循环中旋转，试图尽可能快地进行消息传递。其他进程没有获得任何 CPU 周期并且永远不会进展。使用以下命令强制此模式：mpirun -np N --mca mpi_yield_when_idle 0 ./a.out
降级忙等待。如果您超额订阅（进程数>处理器数）很有用，进程经常让出处理器，从而允许多个进程进行。如果您没有超额订阅，则比激进模式稍慢。使用以下命令强制此模式：mpirun -np N --mca mpi_yield_when_idle 1 ./a.out
轮询。这个你必须自己设置，例如，通过调用MPI_Iprobe()循环sleep调用。
我可以确认通过阻塞等待接收进程以 100% 的速度旋转。他们可能处于某种轮询循环中。
MPI_Wait调用中。MPI_Test处理未完成的请求。我很确定我之前听说过 MPI 等待操作（在大多数 MPI 包中）是使用自旋锁实现的——即，处理器卡在一个循环中（全速运行）一遍又一遍地检查是否有任何信息进来了。
我不是 MPI 设计师，所以没有背景说明为什么做出这个决定——但听说这是有充分理由的。
自旋锁很糟糕，因为其他进程中的其他线程可能已经使用了 CPU。是的，从操作系统的角度来看，轮询线程始终处于运行状态，这会阻止 CPU 调低时钟以节省电力。理想的实现是让线程等待某个同步对象，并在数据到达时得到通知。