关于 MONITOR-MWAIT 与 HLT 指令，我提出了一个奇迹。两者都停止处理器，都在各种外部触发器（中断等）上唤醒。
在我的实验中，考虑到 HLT 和 MWAIT 的功能几乎相同：
（当然，MWAIT 可能是更高的分辨率，我没有测量分辨率，但它似乎通过（我假设）中断等过度唤醒）..所以我看不到很大的优势。
谢谢，任何以这种方式提出的想法将不胜感激
为了表现；最重要的是，无论何时发生等待（HLT 的 IRQ，或 MWAIT 的 IRQ 或内存写入），CPU 退出其“等待”状态所需的时间。这会影响延迟 - 例如，在启动中断处理程序或实际发生任务切换之前需要多长时间。CPU 从等待状态出来的时间对于不同的 CPU 是不同的，对于同一个 CPU 上的 HLT 和 MWAIT 也可能略有不同。
这同样适用于功耗——等待时的功耗在不同的 CPU 之间可能会有很大差异（尤其是当您开始考虑诸如超线程之类的事情时）；HLT 与 MWAIT 的功耗和功耗在同一 CPU 上也可能略有不同。
对于使用，它们适用于不同的情况。HLT 用于等待 IRQ，而 MWAIT 用于等待内存写入发生。当然，如果您正在等待内存写入，那么您需要决定 IRQ 是否应该中断您的等待（例如，如果您只想等待内存写入，您可以这样做）CLI。MWAIT
然而，对于多任务系统，大多数情况下它们都只用于同一件事——在 CPU 空闲的调度程序中。在引入 MONITOR/MWAIT 之前，调度程序会在等待工作完成时使用 HLT（以减少一点功耗）。这意味着，如果另一个 CPU 解除阻塞一个任务，它不能只是将该任务放入调度程序的队列中，并且必须向 HLTed CPU 发送一个（相对昂贵的）“处理器间中断”以将其从 HLT 状态中剔除（否则当有工作可以/应该做时，CPU 将继续无所事事）。使用 MWAIT，这种“处理器间中断”（可能）是不必要的 - 您可以设置 MONITOR 以监视对调度程序队列的写入，以便将任务放入队列的行为足以导致等待的 CPU 停止等待.
也有一些研究将 MONITOR/MWAIT 用于诸如自旋锁和同步之类的事情（例如等待释放竞争锁）。这项研究的最终结果是 CPU 退出其“等待”状态所需的时间太长，并且像这样使用 MONITOR/MWAIT 会导致过多的性能损失（除非存在设计缺陷 - 例如使用自旋锁当你应该使用互斥锁时）。
我想不出任何其他原因（除了调度程序和锁定/同步）来使用 HLT 或 MWAIT。
HLT 指令实现了单个线程可用的最浅空闲电源状态 (C-State)，而 MWAIT 指令允许您请求所有可用的空闲电源状态以及子状态。
在硬件层面，执行 HLT 相当于执行状态提示为 0 的 MWAIT。这将处理器置于 C1 状态，即内核的时钟门控。如果您想进入更深的 C 状态以对内核进行电源门控并可能对封装进行电源门控，则必须使用 MWAIT。
对于各种电源状态，在节能和退出延迟之间总是存在权衡。C-State 越深，省电越多，但退出 C-State 所需的时间越长。您还应该注意，现代 x86 处理器将根据中断频率限制电源状态的深度（即，如果您每 1 us 接收一次中断事件，硬件将不会尝试以 2 us 退出进入 C 状态潜伏）。
除了硬件禁止进入 C-State 之外，一些 C-State 只能通过线程之间的协调进入。例如，在具有超线程的 Intel x86 处理器上，内核中的两个线程都必须请求电源门控 C-State 才能在内核级别发生电源门控，同样，一个包中的所有内核都必须请求一个包- level power-gated C-State 用于在封装级别进行电源门控。硬件一般遵守最浅的请求，所以如果1个线程请求C1，另一个线程请求C3，处理器进入C1。
如果您不控制操作系统，那么这确实是一个有争议的问题（因为 MWAIT 仅在 CPL0 可用）。如果您“拥有”操作系统，那么使用 MWAIT 而不是 HLT 几乎总是有意义的，因为它在许多情况下可以节省更多的电量，并且可以访问与 HLT 相同的空闲电源状态。
MONITOR/MWAIT应该可以“用于诸如自旋锁和同步之类的事情（例如等待释放竞争锁）”。
然而，MONITOR/MWAIT (a) 出于一个非常愚蠢和恼人的原因，不得不被限制为只能由 ring 0 内核代码使用，而不是用户代码，并且 (b) 加载了微码以进入低功耗睡眠状态。
一些公司已经更好地实现了类似或等效的指令，例如MIPS的LL/PAUSE大致相当于MONITOR/MWAIT。