处理器流水线状态保存答案

【问题标题】：Processor pipeline state preservation处理器流水线状态保存
【发布时间】：2015-09-11 14:28:14
【问题描述】：

在线程休眠/上下文切换/中断等期间，是否会保存处理器管道的状态（已解码或预取指令）并随后在恢复后重新加载？（可能是一种优化）。

【问题讨论】：

您是否准备好计算像 Transmeta/Denver 这样的代码翻译 VLIW 微架构（以一阶近似）几乎工作？ :P
很高兴知道:)。但我主要关注 x86_64 和 ARM 架构。
Transmeta 的 crusoe 设计是 x86 CPU。在内部，它是通过 JIT 将 x86 机器代码编译为 VLIW 机器代码并对其进行缓存来实现的。因此，它会一次性找到并行性，并且不必在每次 x86 架构状态通过相同代码时立即执行此操作。这就是@Notlikethat 的目的。

标签： linux-kernel arm x86-64 cpu-architecture

【解决方案1】：

这对于我所知道的任何 CPU 都是不可能的。没有执行此操作的接口，也没有 CPU 自行执行此操作的条件。将大量内部 CPU 状态转储到 RAM 将花费比它节省的更多周期。让操作系统跟踪为此所需的可变大小的 RAM 块只会使开销变得更糟。

如果有什么值得保存的话，顺便说一句，这将是已经执行的指令的结果，由于缓存中丢失的加载，还不能退出。（主流 ISA 的所有常见无序执行设计都使用按序引退来支持精确的异常。已经提出了带有检查点/回滚异常和错误预测的无序引退。搜索千指令处理器，IIRC。 )

（有缺陷的想法）：激进的乱序设计可以通过在外部中断到达时延迟写入中断返回地址来避免在上下文切换上浪费太多工作。也就是说，他们可以通过允许流水线中已经存在的一些指令继续执行来假装中断来得晚。如果在中断处理程序返回之前不需要用户空间指令指针，CPU 可以清除流水线。

Hrm，这有一个主要的困难，即进入中断处理程序的寄存器值也取决于架构状态，所以这可能行不通。

这个定义。不能用于用户空间产生的中断，因为它修复了返回地址。

对于在等待带有monitor / mwait 或其他东西的自旋锁时使自己进入睡眠状态的线程来说，这不是问题。 mwait 大概是在它退休之前不会生效，并且在之前的所有工作都完成之前它不会退休。我认为，它会破坏 CPU 积极地推测性地执行过去 mwait 的预期目的。或者mwait 甚至不冲洗管道，只是节省电力。

【讨论】：

我会接受这是正确的答案，因为你很好地证明了在一般情况下并非如此。
@chamibuddhika：如果您知道任何特定情况下会执行此类操作，我很想听听。 AFAIK，任何最大限度地减少有用数据丢弃的优化都完全在 CPU 内完成，没有软件控制或可见的架构状态。我能想到的一种情况是，数据缓存由 VM 上下文标记，因此在管理程序和来宾之间切换不必使缓存无效。实际上，这可能涉及软件检测该功能并且不运行缓存无效指令。谷歌详细信息...
不是我知道的。

【解决方案2】：

这个想法已经被提出，但您需要一种密度更高的内存技术，这种技术现在才可用。例如看这篇论文：

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6489970

基本上，他们提出了由一组基于忆阻器（电阻式非易失性存储器组件）的新锁存器和寄存器组成的管道，可以保存对应于多个线程的多个值。然后，控制逻辑可以告诉所有锁存器哪个线程应该处于活动状态，并允许在整个管道中同时进行上下文切换。

请记住，这只会提高闩锁级别的粒度。具有同时多线程的现代 CPU 已经可以在不同的单元级别上激活不同的线程，而无需上下文切换，通过仲裁很简单。其他具有固有并行性的单元可能已经在每个周期处理多个线程（例如 - 多端口 ALU）

【讨论】：