面向E级高性能计算的软件栈（三）

3. 当前关注领域

在本节中，我们将讨论当前的PMIx标准工作组，以及他们正在设计的接口如何帮助降低开销并提供新功能。除非指定，否则这些功能存在于当前的v2.0规范中，并在相应的v2.x参考实现中得到支持。

3.1 协调启动过程

正如前面所讨论的，应用程序启动期间的最大时间成本历来是集体共享连接端点信息(BCX)所需的时间，其次是开始操作之前的屏障（barrier）。对交换数据的分析显示，在启动应用程序进程时，BCX中90%以上的信息为本地RM守护进程所知，但是守护进程没有将这些信息传递给客户机进程的机制。其余部分是动态分配的端点连接，客户端独立地发现这些连接，然后将其贡献给集体操作。

考虑到这一点，PMIx社区开始着手启动程序，目标是完全消除BCX和随后的全局屏障，而不管应用程序的规模如何。此外，社区认为，通过预先定位所需的信息，可以有效地消除文件系统检索瓶颈。修改后的发布顺序如下图3所示(红色的步骤表示PMIx参考库v2.1中实现的操作):

 

 

第零阶段。尽管从技术上讲不是启动过程的一部分，但资源清单inventory （包括NIC，交换机，网络和节点拓扑，内存和CPU等）对于调度应用程序以及有效完成启动过程至关重要。考虑到修订后的启动过程的广泛信息需求以及PMIx作为跨系统集成商的作用，要求PMIx社区提供一种动态的方式来组装清单并在发生更改时对其进行更新。因此，社区提供了三种资源清单支持机制：

• 启动时的资源清单汇总。添加了PMIx_server_collect_inventory API，以请求PMIx采样本地拓扑并将信息返回给主机守护程序，以汇总到WLM。当然，这仅限于PMIx实现支持的任何信息。PMIx参考库目前使用hwloc实现这个目的，从而提供可用cpu、内存、gpu和网络接口的拓扑信息。如有需要，将提供更多的支持;
• 根据要求查询SMS子系统。在rollup期间提供的信息仅是本地的，即， PMIx将报告位于其节点上的资源。WLMs和其他库存消费者还需要了解将节点连接在一起的系统元素——例如，交换机的标识及其连接模式，以及消息的节点到节点的传输时间。这个信息最好通过直接查询各个子系统来获得。例如，网络上的信息通过系统FM的请求获得，然后提交到WLMs节点上的PMIx键值存储；以及
• 通过PMIx事件通知进行更新。由于设备更换或临时停机(例如，网络瓶颈)，资源清单信息可能会随着时间而改变。不断轮询信息会给系统带来不必要的压力。因此，PMIx社区正在与子系统提供者合作，以获得更改通知，这些更改可以直接作为PMIx事件提供，也可以由PMIx服务器转换为此类事件。这些事件随后用于更新键值存储并向注册方发出更改警告。

此信息通过PMIx_Query API提供给WLM(用于调度操作)以及任何其他相关方。本地资源信息(例如，存储器和CPU拓扑)也被高速缓存在每个节点上的共享存储器中，以供应用程序以后使用。

第一阶段。用户向WLM提交作业（以脚本或交互式会话请求的形式）。该请求通常将包含作业所需资源的类型和数量的描述。除了将请求记录到适当的队列中之外，WLM还使用PMIx接口将请求传递到文件系统，以获取所有用户标识的可执行文件，支持库和数据文件的估计检索时间。然后，可以将得出的估计值纳入调度算法中-随着热/热/冷存储策略变得越来越普遍，这尤其重要。

用户识别所有所需库的负担通常是一个问题。因此，PMIx提供了另一个接口，通过该接口，WLM可以首先请求分析作业脚本以返回关联库的列表(例如，等同于标准POSIX LDD命令的输出)，该列表可以包括在FS请求中以获取时间。预计日益精确的分析器的开发将成为人们感兴趣的研究领域。

第二阶段。根据资源可用性、相对优先级和调度算法，WLM将在未来的某个时刻将资源分配给所请求的作业。这种分配通常发生在WLM被通知作业完成并且恰好在启动先前作业的尾声部分之前，但是许多WLM还利用预期调度来识别将在不同终止场景下运行的一个或多个作业。此外，为较大的作业聚集资源的需要经常导致分配的至少一部分在滚动的基础上变得可用。因此，在新调度的作业开始之前，经常有一定量的时间可供SMS用于对分配进行预处理。

PMIx利用这段时间来完成两个重要步骤。 首先，它提供一个接口，WLM可以通过该接口通知FS分配，并将在初始阶段确定的所需文件列表传递给FS。 假设此类缓存元素可用，这将允许适当启用的文件系统将文件预缓存到分配的计算节点附近的位置网络中。 如果文件系统支持网络与计算结构是分开的，则缓存操作可以基于预期的分配位置在后台执行，而对当前正在运行的应用程序几乎没有影响。 缓存完成后，文件系统将生成PMIx事件（由WLM监视）。

其次，WLM可以利用另一个PMIx接口将分配和作业描述都传递给子系统（例如FM结构管理器），并接收一个“ blob”，其中包含每个子系统已确定的其分配范围内的本地资源将需要的所有信息，以支持所描述的工作。标记返回的值以标识哪些值将直接提供给每个节点上的本地资源，以及哪些值将作为环境变量传递给应用程序进程，该环境变量在由特定进程初始化时会被资源识别 。例如，某些网络可以使用该应用程序中所有进程的位置“预加载”本地网络库，从而允许该库为任何进程计算所需的地址信息，和/或包括安全令牌以保护进程间通信。

第三阶段。一旦缓存了所需的文件并获得了网络配置，WLM就将初始化“BLOB”连同用于该分配的作业描述和相关inventory 信息(例如，网络感知集合的已分配节点之间的相对网络路由时间)传递给已分配节点上的RM守护程序。在派生任何本地进程之前，每个RM守护进程都可以利用PMIx接口将配置信息传递给本地资源。这允许资源为作业准备任何内部状态表，这一操作可能需要提升的权限，因此不能由应用程序进程本身执行。此外，RM守护进程向本地PMIx服务器注册应用程序和本地进程，为其提供与应用程序和本地环境有关的所有相关信息。PMIx社区已经收集了所需信息的列表，以帮助SMS供应商满足这一要求。完成此操作后，RM守护进程将派生应用程序进程。

第四阶段。在初始化期间，每个进程通过调用PMIx_Init函数连接到其本地PMIx服务器。PMIx服务器通知主机RM连接，并返回本地RM守护进程在注册期间提供的所有信息(或指向数据所在的共享内存的指针)。

此时，启动序列已经完成，应用程序进程可以自由通信。虽然PMIx提供了一些接口，通过这些接口，应用程序进程可以在它们之间全局地交换数据(例如，BCX)，但是这些接口主要用于遗留系统，不建议用于未来的系统。相反，现在的重点是实现免交换操作。

注意，有些操作可能总是需要进程间交换信息。例如，共享内存通信通常要求一个进程创建一个备份文件，并将该文件的名称和位置传递给它的本地对等方。在这种只涉及本地交换的情况下，库可以在发布信息时使用PMIX_LOCAL作用域来将信息限制在同一节点上执行的一组进程中，从而避免任何跨节点交换。在撰写本文时，PMIx社区还没有确定任何主机RM不能提供的非本地范围信息。

完全消除PMIx启动序列中的BCx和初始化时间障碍需要修改交换矩阵管理器和网络接口卡(NIC)库，以及潜在的NIC硬件更改以优化性能。PMIx社区正在与网络供应商合作，在其产品路线图中提供此支持，包括支持：

• 主机地址解析。从历史上看，每个应用程序进程都会独立地发现本地可用的NIC并确定它们的寻址信息(例如TCP地址或GID/LID对)，然后将这些信息“广播”给它的对等方。虽然有时可以解析给定主机名的NIC地址，但是如果没有预先提供寻址信息，可能会导致对SMS解析代理的不可伸缩的主机名解析需求，因此需要进行all-to-all广播。通过让fabric管理器为分配中的所有节点提供任何必需的寻址信息，从而可以将这些信息包含在阶段3中的初始分配设置消息中，从而完成此交换。
• 启动前为每个进程分配集合端点(例如，一个套接字或队列对QP索引)以启动对等通信。这并不排除其他端点的动态分配(例如，多个队列对以增强带宽)，而是提供了一种方法，通过这种方法，两个对等点最初可以彼此联系，以进一步建立它们的通信通道。请注意，如果两个对等点选择使用所提供的端点进行常规通信，则没有限制。
• 意外消息（即在向接收NIC注册过程之前接收到的消息）。由于为进程提供了在启动时与任何对等方进行通信的所有必需信息，因此进程可能会立即尝试将消息发送到尚未启动的远程对等方。当前，网络库可能会丢失消息和/或在发送给接收库未知的进程的通信中返回错误。因此，当前的并行编程库通常在启用通信之前就包括带外屏障操作，以确保所有进程都已实例化并已注册到其本地NIC。如果网络库和/或NIC硬件中包含足够的重试逻辑和缓冲区空间，则可以消除此要求。避免主动重试可能是合乎需要的-例如，接收NIC可能会返回一个特定的错误代码，指示NIC不知道预期的接收者，从而指示发送NIC在重试之前引入一些轻微的（可能是随机的）延迟-以减轻启动过程中不必要的网络拥塞。但是，当前的测量结果表明，即使是百亿亿分之一秒的机器，进程启动之间的时间差也将在十分之一秒的范围内，并且非基准应用程序通常不会立即发送给同级设备-因此，该值采取非常规措施的做法仍有待观察。

实现这三个步骤需要一些时间和努力。在此期间，在fabric不能在应用程序启动前提供所需的端点信息的情况下，PMIx提供了两个可用于提高启动性能的优点。首先，在许多情况下，通过删除本地主机RM提供给每个进程的数据，可以大大减少BCX中包含的数据量。例如，编程库常常让它们的进程发布它们所在位置的主机名和分配的绑定。虽然来自每个进程的信息可能涉及相对较少的字节数，但是流经大型应用程序集合的总数可能会变得相当大。在这种情况下，为了避免在BCX中包含已经通过PMIx提供的数据而检查代码，可以减少BCX集合消息和后续的启动时间。

其次，PMIx支持一种称为直接名片交换（DBCX）的替代连接方法，该方法用按需获取对等方名片来代替阻塞的BCX。因此，不执行BCX本身（和包含的屏障操作）。 每个进程发布的数据都缓存在本地PMIx服务器上。当进程向特定对等方请求名片时，它首先检查本地PMIx共享内存段，以查看数据是否已可用。如果不是，则将请求传递到本地服务器，该服务器随后请求其RM主机从托管指定对等进程的PMIx服务器检索数据。然后，本地PMIx服务器将此数据提供给请求的客户端进程。通常，这是通过将数据放入PMIx服务器的共享内存数据存储中，然后通知客户端进程该数据现在可用来实现的。

虽然DBCX通过消除BCX屏障允许更快的启动时间，但按peer检索名片信息的效率较低。可以实现优化（例如，在第一次请求时从节点上的所有进程返回发布的信息），但一般来说，DBCX仍然最适合连接稀疏的应用程序。

3.2 事件通知

事件通知PMIx工作组的重点是处理故障。出于社区的目的，将故障定义为对应用程序的运行产生负面影响的任何事物。因此，已停顿（即不再在其工作上取得进展）的应用程序被视为发生故障，网络拥塞和硬件组件的故障也被视为发生故障。PMIx通过允许进程注册事件处理程序来减少错误，这些事件处理程序可通过以下方式进行：

• 资源管理器可以将检测到和预期的系统问题通知应用程序，包括抢占该应用程序的意图。 PMIx本身不会生成事件，而是仅发布事件并收集可能从事件中产生的响应。因此，PMIx提供了一个抽象层，以帮助促进RM集成到提供此类警告的子系统（例如，监视系统）；
• 应用程序进程可以将已检测到的问题（例如，与peers的通信中断）通知其peers和/或SMS。 接收到事件后，应用程序可以使用PMIx与RM交互以标识对事件的所需响应，包括请求替换节点，从给定检查点重新启动特定进程或RM支持的任何其他操作；以及
• SMS子系统（例如结构管理器）可以响应故障而将流量拥塞或重新路由操作通知给资源管理器。这些通知随后将转发到任何已注册的应用程序。

事件可以分为两个不同的类。特定于作业的事件与在会话中执行的作业直接相关，例如调试器附着或相关作业中的进程失败。此类别中的事件将立即传递到PMIx服务器库，以便转发到相关的本地进程。相反，环境事件包括ECC错误、温度变化和其他直接影响会话资源的非作业条件。请注意，尽管这些确实影响会话的作业，但它们并没有直接引用这些作业——即，在未指定特定目标的情况下生成了事件。因此，只有在请求时才将此类事件交付给PMIx服务器库。

SMS元素和应用程序都可以注册这两种类型的事件。注意，竞态条件可能导致注册发生在可能感兴趣的事件之后(例如，在执行开始之后但在注册之前发生的内存ECC事件)。SMS供应商被要求将此类事件缓存一段时间以缓解这种情况，但不是必须这样做。因此，应用程序必须意识到，它们可能不会接收到在注册之前发生的环境事件，这取决于主机SMS的功能。

事件生成器可以指定交付该事件的目标范围。因此，生成器可以选择将通知限制为本地节点上的进程，与生成器相同的作业内的进程，相同分配内的进程，相同进程内的其他线程，仅SMS（即，不限于任何应用程序进程） ，所有应用程序进程或基于特定进程标识符的自定义范围。 仅会通知给定范围内的进程以及注册所提供事件代码的进程。

事件通知提供事件源的进程标识符，以及事件代码和生成器提供的任何其他信息。 当进程接收到事件通知时，将扫描已注册的处理程序以获取其事件代码，并将匹配的处理程序组合到事件链中以进行服务。注意，用户还可以在注册事件时指定源范围(使用前面描述的相同范围指示器)，以进一步限制调用它们的时间。在组装时，PMIx事件链是基于事件处理程序的特殊性和处理程序注册时的用户指令来排序的。默认情况下，处理程序根据触发回调的事件代码的数量分为三类:

• 首先服务单个代码处理程序，因为它们是最具体的。这些是针对一个特定事件代码注册的处理程序。
• 一旦完成所有单个代码处理程序，就服务于多代码处理程序。一旦接收到与所提供的任何代码相匹配的事件，处理程序将被包括在链中。
• 一旦完成所有多代码处理程序，就会服务默认处理程序。这些处理程序总是包含在链中，除非生成器专门排除它们。

用户可以在注册时在其类别中指定处理程序的回调顺序。可以通过提供相关的返回事件处理程序注册ID来指定顺序，也可以使用事件处理程序名称(如果用户在注册相关事件时指定了事件处理程序名称)来指定顺序。因此，如果两个处理程序都出现在事件链中，用户可以指定在另一个处理程序之前或之后执行给定的处理程序(如果不包含另一个处理程序，则忽略排序)。请注意，顺序并不意味着直接的关系。例如，在事件处理程序A之后注册的多个处理程序都将在A之后执行，但不能保证它们之间以任何特定的顺序执行。

此外，可以将一个事件处理程序声明为链中要执行的第一个处理程序。如果传入的事件与指定的范围和事件代码相匹配，则总是在任何其他处理程序之前调用此处理程序，而不考虑类别。只能指定一个处理程序—尝试将其他处理程序指定为“first”将返回一个错误。注销声明的“first”处理程序将重新打开该位置。

类似地，可以将一个事件处理程序声明为链中最后执行的处理程序。请注意，如果前面的处理程序终止了链，则不会调用此处理程序。只能将一个处理程序指定为“last”—尝试将其他处理程序指定为“last”将返回一个错误。注销声明的“last”处理程序将重新打开该位置。

在完成其工作并在返回之前，每个处理程序必须调用事件处理程序完成函数(包括状态代码和要传递给后续处理程序的任何信息)，以便调用链可以继续进行。PMIx自动将每个处理程序的状态和结果(在完成回调中提供)聚合到之前所有处理程序的状态和结果，以便链中的每个步骤都充分了解之前的情况。

事件处理程序可以通过将PMIX_EVENT_ACTION_COMPLETE状态传递给完成回调函数来终止链上所有进一步的进展。当前，PMIx引用实现中的所有事件链都在默认PMIx进程线程中执行。允许每个链在自己的专用线程中执行的未来选项正在考虑之中。