使用 mvapich2 与 openmpi 比较 MPI 线程死锁期间的 CPU 利用率

Comparing CPU utilization during MPI thread deadlock using mvapich2 vs. openmpi

我注意到当我有一个死锁的 MPI 程序时,例如wait.c

#include <stdio.h>
#include <mpi.h>


int main(int argc, char * argv[])
{
    int taskID = -1; 
    int NTasks = -1; 
    int a = 11; 
    int b = 22; 
    MPI_Status Stat;

    /* MPI Initializations */
    MPI_Init(&argc, &argv);
    MPI_Comm_rank(MPI_COMM_WORLD, &taskID);
    MPI_Comm_size(MPI_COMM_WORLD, &NTasks);

    if(taskID == 0)
        MPI_Send(&a, 1, MPI_INT, 1, 66, MPI_COMM_WORLD);
    else //if(taskID == 1)
        MPI_Recv(&b, 1, MPI_INT, 0, 66, MPI_COMM_WORLD, &Stat);

    printf("Task %i :    a: %i    b: %i\n", taskID, a, b); 

    MPI_Finalize();
    return 0;
}

当我使用 mvapich2-2.1 库(它本身是使用 gcc-4.9.2 编译的)编译 wait.c 和 运行 它(例如 mpirun -np 4 ./a.out)时,我注意到(通过top),所有 4 个处理器都以 100% 的速度运转。

当我使用 openmpi-1.6 库(它本身是使用 gcc-4.9.2 编译的)编译 wait.c 和 运行 它(例如 mpirun -np 4 ./a.out)时,我注意到(通过 top),2 个处理器以 100% 和 2 个 0% 的速度运转。

推测0%的2是完成通讯的吧。

问题:为什么 openmpi 和 mvapich2 在 CPU 用法上存在差异?这是预期的行为吗?当 CPU 使用率为 100% 时,是否来自不断检查消息是否正在发送?

busy-waitMPI_Recv() 上的两种实现,以最大程度地减少延迟。这解释了为什么两个 MPI 实现中的任何一个的等级 2 和等级 3 都为 100%。

现在,显然排名 0 和 1 进入 MPI_Finalize() 调用,这就是两个实现的不同之处:mvapich2 忙等待而 openmpi 没有。

回答您的问题:是的,他们在检查是否已收到消息时处于 100%,这是预期的行为。

如果您不在 InfiniBand 上,您可以通过将 strace 附加到其中一个进程来观察这一点:您应该在那里看到许多 poll() 调用。