点击上方蓝色字关注我们~

Short waits with umwait

By Jonathan Corbet
June 13, 2019

user-space的进程可以利用很多种kernel提供的机制来等待某个event的发生。不过对那些极短时间（例如几个微秒量级的）的wait操作来说，调用到kernel space不是一个好主意。这么短时间的等待操作，一般的开发者都会用busy loop来实现，因为busy loop可控，一般不会等到很长时间之后才返回。当然，busy wait有自己的缺点，因此Intel提出了一组指令来专门支持这类短时间的delay。Fenghua Yu提交了一组patch来利用这些指令，目前正在进行review。

利用busy wait当然会占用处理器的资源，甚至还不如利用这个资源来挖矿（比特币等）。busy wait导致的发热和功耗是彻头彻尾的纯粹浪费。在超线程(hyperthread)CPU上，busy wait的进程抢占了资源，有可能让原本采用hyperthread机制共同占用这个处理器的另一个线程无法得到执行。总之，最好能让CPU只是稍微wait很短的一个时间，一有事件发生就马上恢复执行。

因此，Intel提供了3个新的指令。umonitor 指定了一个address和一个size，提供给CPU，让它知道当前运行的application在等待有人往这个指定内存区域写入数据。而umwait指令则是让处理器停止执行，直到上述的写入操作真的发生了。这样CPU就可以进入低功耗状态或者开始执行hyperthread对应的另一个线程了。这个指令还利用两个寄存器提供了超时机制，CPU不会无限制的等待，而是等到timestamp counter (TSC) 的值超过预设的值之后就马上醒来。如果一段代码只想利用这个超时机制，不需要监测对地址的写入，那么可以直接利用tpause指令来暂停CPU一段时间。

需要注意的是，他们都不是特权指令，也就是任何进程都可以使用。通常来说，能暂停处理器（或者放入低功耗模式）的指令都是特权指令，普通进程无法使用。对上述指令来说，最终实现了一个机制，让kernel能对CPU的睡眠时长设置一个上限，这样umwait和tpause指令在达到上限的超时之后就会恢复正常执行了，不至于被利用来做DoS攻击。Yu的patch set通过下列接口允许系统管理员来通过sysfs文件配置这个上限值：

因为这里用到了TSC（timestamp counter），所以这个值是处理器的cycle数，却省事100,000，也就是1GHz CPU的大约100us时间。这个值是Andy Lutomirski在1月份对此前版本patch set讨论时提出的建议，他的理由如下：“我建议我们应该把这个缺省值设小一点，比如100微秒。我认为这里选值的原则是要达到数倍于C0.2的进出延迟时间这样我们才能计生功耗以及SMT资源，同时又要尽量小，这样大家不会认为UMWAIT只是以前的REP NOP的微小改进版本。”

这里提到的“C0.2”是CPU在上述两个新指令执行后可能进入的两种低功耗状态之一，而另一个低功耗状态就命名为C0.1。其中C0.1状态是一个浅层睡眠状态，能节省的功耗非常有限，但是能够更快的进出。C0.2就比C0.1要睡得更深一点，也就能节省更多功耗，同时也需要更长的时间才能退出到正常执行状态。

系统管理员在某些情况下很可能不愿意让系统进入C0.2状态，例如它如果正在处理一些需要实时响应的任务的时候。所以在上述sysfs目录里面还有一个enable_c02节点，可以用来关闭C0.2状态而只能进入C0.1状态。缺省配置，是允许进入C0.2这个更深的睡眠状态的。

Lutomirski在上次讨论的时候，还担心这些指令可能会有一些安全方面的争议，因为它在让进程监控一个内存区域。他的原话是umwait “看起来是个能用来在高带宽场景下的监控工具，并且对Spectre类型的攻击来说也会更加方便了”。他并没有描述具体可以怎么用，不过相信不久之后可能会有一些学术论文来讨论这些影响。Yu回应说这些指令可以被彻底关闭掉（当然会导致性能下降不少），只不过目前还没有提供类似的sysfs节点供系统管理员来设置。同时，这些指令（会在即将发布的“Tremont”处理器里实现）对某些特定类型的任务来说确实会有价值。目前关于这组patch set的大多数comment都已经处理完毕，剩下很少了。所以很可能kernel不久之后就能支持umwait这种指令了。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～