[发明专利]用于对CPU内的消息通道基础设施的多流访问的虚拟化通信套接字

说明书

技术领域

本申请涉及多处理器系统、可移植机器代码以及消息通道事务处理。

背景

图1示出根据某些实施例的多处理器系统500的简化框图。多处理器系统500包括N个中央处理单元(CPU)150A、150B、150N(统称为“CPU 150”)，其可耦合到N-1个专用总线，被称为快速通道互连(QPI)总线160A、160B、160N-1(统称为“QPI总线160”)。QPI总线160(专门为CPU设计)加速了CPU 150之间的通信。CPU还可耦合到一个或多个易失性存储器(未示出)。

多处理器系统500的特征还包括通过高达N条专用总线(被称为直接媒体接口(DMI)总线170A、170B......170N)耦合到CPU 150的高达N个外围控制器中枢(PCH)180A、180N(统称为“PCH 180”)。PCH 180在多处理器系统500的CPU 150以及一个或多个外围设备之间形成接口。PCH 180可包括显示器、输入/输出(I/O)控制、实时时钟以及其他功能并且可连接到集成显示器以及其他外围设备，诸如键盘、鼠标、非易失性存储设备等等。

对于多处理器系统500或基于单处理器的系统的处理器内的端点之间的通信而言，使用消息通道。该消息通道是用于这些通信的传输介质，并且可被认为是处理器内部的端点之间的“隧道”或“地道”类型。可存在许多消息通道端点，并且可将消息从任何端点发送到任何其他端点，其中，这些端点是处理器内的功能实体。可移植机器代码或pcode用于这些实体之间的通信，并且pcode具有其自身的用于向其他端点发送消息的端点。(没有端点向pcode发送自主消息，因为pcode端点接收到的唯一消息是对pcode发起的消息的响应。)功率管理请求(QMReq)消息使用QPI总线去往其他实体，这类似于消息通道，除QPI总线是外部总线/接口之外。相比之下，消息通道严格地位于处理器内部。

在基于CPU的系统内，诸如单处理器系统或图1的多处理器系统500，消息通道由许多分散的pcode流和函数使用。这些函数可用于对单核控制寄存器进行读和写、发布PMReq以及向其他平台实体(例如，其他CPU 150、PCH 180)发送消息。pcode非常频繁地使用消息通道，从每毫秒数百次到每毫秒数千次。

某些更新的多处理器系统被设计的方式为使得消息通道在不同的时刻(诸如在频率跃迁期间)变得阻塞。先前的多处理器系统没有这种问题，因为其消息通道接口总是完全功能性的。所以，先前项目中的pcode可以通过向消息通道发送事务并且在密封环中等待事务完成，来以“阻止”的方式使用消息通道。

对于更新的多处理器系统，在消息通道上使用“阻止”事务被认为是不可接受的，因为阻止事务可潜在地锁定pcode持续若干毫秒。因此，阻止事务导致其他(非消息通道相关的)功能的更高延迟并且影响CPU的性能。此外，存在锁死的风险，因为消息通道由等待通过边带接口来自pcode的某个东西的某个功能阻止，但是pcode被阻止，等待消息通道事务完成。

此外，PMreq消息要求对PMReq引擎(PME)中的单个缓冲器的使用的仲裁。PMreq消息通过消息通道到达PME，并且然后通过QPI总线160到达另一个CPU 150(或者通过DMI总线170到PCH 180)。作为PMreq协议正确性的一部分，PME将等待来自另一个CPU/PCH的完成(CMP)并且将保持PMreq缓冲器锁定，直至实际接收到完成。在这种情况下，如果使用阻止消息通道事务，pcode将被锁定持续PMreq/CMP交换的整个往返持续时间。另一个CPU上可存在延迟(由于频率变化等等)，其进一步延长锁死的持续时间。

因此，存在对克服现有技术的缺点的解决方案的持续需要。

附图简要描述

当结合附图时，前述方面和本发明的许多伴随优势将变得更加容易认识到，正如通过参照以下详细描述更好地理解到的那样，其中，贯穿各种视图，相同的参考标号指代相同的部件，除非另外指明。

图1示出根据某些实施例的多处理器系统的简化框图；

图2是根据某些实施例的消息通道优化方法和系统的简化框图；

图3是示出根据某些实施例的两个任务的任务流的流程图；

图4是示出根据某些实施例的与图3中的任务相同的两个任务的任务流的流程图，这次使用图2的方法和系统；

图5是根据某些实施例的如由图2的消息通道优化方法和系统处理的消息通道发送操作之后的流程图；以及