LWN：CPU affinity怎么才能不那么死板？

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

Soft CPU affinity

By Jonathan Corbet
July 4, 2019

有些NUMA系统上有许多CPU，也就经常会需要把一些workload分配到某些指定处理器上去。这样做的好处是能改善性能，同时避免它影响其他处理器。目前kernel里的实现方式可能有点过分保护了，导致有些CPU忙得不得了的时候，可能其他有些CPU还很空闲。Subhra Mazumdar提出了一组soft affinity patch set希望能改善这些性能。

目前，进程可以被限制在一部分CPU上才能执行，也就是利用sched_setaffinity()系统调用或者cpuset机制来实现。这两种方法都会导致这个进程只能在这些CPU上执行，完全不会管系统里其他CPU的赚狂。所以其他CPU哪怕是在idle状态，也不能帮此进程什么忙。通常来说这个行为是正确的，系统管理员把CPU分成多组之后就是希望能让各组CPU做专门的工作。

不过，加入系统管理员有不同看法，他其实想让这个分组操作不那么强硬，而是希望让那些idle CPU也能帮这个进程的忙呢？那么唯一的办法就是不要分组，让进程可以在任何一个CPU上运行。不过这样的话，进程之间没有隔离，NUMA节点的本地优势也就没有了，会导致性能下降。理论上来说AutoNUMA的平衡代码应该能改善这个问题，主要是在迁移进程和相应memory的时候都主要考虑同一个NUMA node之内。不过Mazumdar发现如果memory分布在系统各处的时候，这个机制工作的不太好。并且响应时间也台湾，page scan的开销会很大。

所以Mazumdar想了另一个办法，是创建一个“soft affinity”的概念。首先增加一个系统调用：

前三个参数跟sched_setaffinity()一致，都是用来指定进程以及相应的CPU mask的。flags参数是新加的，如果设置为SCHED_HARD_AFFINITY，这个函数调用后就跟sched_setaffinity()一样，强制限制进程只能在给定的CPU mask指定的CPU上跑。相应的，如果设成SCHED_SOFT_AFFINITY，就会设一个“温柔”一些的CPU mask限制（当然一定要是hard mask的子集），从而引入这个新加的行为。soft-affinity CPU mask跟此前的“hard” affinity在大部分时候是一样的，也就是进程会只在mask指定的CPU上执行。不过，假如这些CPU都太忙了，而其他不在这个soft mask之内、但是在CPU的hard-affinity mask允许之内的CPU,基本是空闲的，那么进程就也可以在这些idle CPU上运行。这样进程就可以在系统里更加分散开来，不过这一切只有在利用率很低的CPU上才会发生。

也就是说，这组patch事实上创建了两级CPU affinity mask（目前的kernel里只有一级）。这两级mask都缺省包含了系统里所有的CPU。hard mask的行为跟此前一致，不过新加的soft mask就用来更进一步的限制进程只能在更少的处理器上执行，不过这个限制可以在kernel认为必要的时候来自己决定临时放开，也就是在hard mask里指明的CPU有空闲的时候。

kernel需要在合适的时候下决心来放开这个进程的soft-affinity mask限制，它主要是根据两个sysctl节点来决定。一个是sched_allowed，另一个是sched_preferred。加入sched_allowed除以sched_preferred之后的比例，高于soft-affinity列表中CPU占用率比起其他某个CPU的比例高，那么这“某个”CPU就可以被选来运行这个task。缺省值sched_allowed是100，sched_preferred是1，也就是soft-affinity mask之外的CPU workload只占soft-affinity之内的CPU的1%，那么进程就会被挪过去。这个100:1的比例其实要求很高了，目标CPU基本只有在完全空闲的情况下才能达到要求。服务器上真正用到这个机制的时候，系统管理员最好根据情况来把这个参数仔细调整以下。

patch set里还有一个未解问题。就是假如进程迁移过去之后，目标CPU的CPU占用率增长上去，这个该怎么办？soft-affinity的决策都是在进程被wake up的时候来决定的，所以这个进程迁移过去之后会一直待在这里运行，直到它sleep之后下一次wake up才会可能变化。如果sleep时间非常断，那么该进程在wake up的时候很可能会被再次迁移。

patch set附带的benchmark结果看到对某些workload有7%的性能提升，而某些场景则是性能下降。大多数的提升都不大，而且数据看起来不是很稳定。Reviewer也对Mazumdar说的AutoNUMA balancing的缺陷有一些看法，他们觉得是不是更应该来改善AutoNUMA的代码，而不是增加一个新的机制以及一组新的scheduler调整参数。

所以，这组patch set目前还是前途未卜，至少在合入之前还有不少工作要做。不过确实有不少需求希望能把每个CPU的计算力都充分利用起来，所以甚至哪怕只有很小的性能提升，在data center数据中心这种场景里都是很有价值的。Soft affinity不知道是不是最终的解决方案，但是确实证明了kernel确有需要对这种场景多加考虑。

全文完

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

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

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