Linux kernel 处理器管道状态保持

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

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

顺便说一句，若有什么值得保存的话，那个么它将是已经执行的指令的结果，因为缓存中丢失了一个负载，所以该指令还不能失效。（主流ISA的所有常见无序执行设计都用于有序退役，以支持精确的异常。已经提出了针对异常和预测失误的检查点/回滚无序退役。Search kilo指令处理器，IIRC。）

---

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

Hrm，这有一个主要的困难，即在进入中断处理程序时注册值也取决于架构状态，因此这可能无法工作

这是def。无法处理由用户空间生成的中断，因为这会修复返回地址

---

对于那些在等待带有

monitor/mwait

或其他功能的自旋锁时将自己置于睡眠状态的线程来说，这不是一个问题

mwait

大概在它退役之前不会生效，而且在之前的所有工作完成之前它也不会退役。我认为，CPU在推测性地执行过去的

mwait

时表现得咄咄逼人，这将违背其预期目的。或者，

mwait

甚至不冲洗管道，只是省电。

这个想法已经被提出，但是你需要一种更密集的内存技术，这种技术直到现在才开始使用。例如，参见本文：

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

---

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

您准备好计算代码转换VLIW微体系结构（如Transmeta/Denver）的数量了吗（一阶近似值）几乎可以这样工作：p很高兴知道：）。但我主要关注的是x86_64和ARM架构。Transmeta的crusoe设计是x86 CPU。在内部，它是通过JIT将x86机器代码编译成VLIW机器代码并缓存来实现的。因此，它只需找到一次并行性，而不必每次x86体系结构状态经过同一代码时都要动态地找到并行性。这就是@Notlikethat的意思。我将接受这一正确答案，因为你提出了一个很好的理由，证明在一般情况下并非如此。@chamibuddhika：如果你知道任何类似的具体情况，我想听听。顺便说一句，任何最小化有用数据丢弃的优化都完全在CPU内部完成，没有软件控制或可见的体系结构状态。我能想到的一种情况是，数据缓存由VM上下文标记，因此在虚拟机监控程序和来宾之间切换不必使缓存失效。实际上，这可能涉及软件检测功能，而不是运行缓存失效指令。谷歌的细节…不，我不知道。