LWN:修复asymmetric CPU packing 中的小问题!

2023-10-14 12:59

本文主要是介绍LWN:修复asymmetric CPU packing 中的小问题!,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

关注了就能看到更多这么棒的文章哦~

Fixing a corner case in asymmetric CPU packing

January 7, 2022
This article was contributed by Marta Rybczyńska
DeepL assisted translation
https://lwn.net/Articles/880367/

Linux 支持系统中的 CPU 具有不同的处理能力的体系架构。例如,Arm big.LITTLE 系统就将高性能且更耗电的 CPU 与比较慢但是功耗效率更好的 CPU 结合了起来。Linux 多年来也一直支持同步多线程架构(SMT,Simultaneous multithredaing),其中每一个 CPU 都会执行多个独立的运行线程 thread,这样看起来就好像是有多个 CPU core 一样。一些架构中混合了这两种方法。最近 Ricardo Neri 提交的 patch set 所引发的讨论就表明,在这些系统上 scheduler 可能在以很低效的方式来分配任务。

Simultaneous multithreading

SMT 功能多年来在 PowerPC 和 x86 等架构中一直存在。SMT 系统中的 CPU 可以从两个(或多个)独立的执行上下文中获取并运行指令。每个逻辑线程(logical thread)看起来都像是一个独立的 CPU,所以一个物理上真正的 CPU 运行着两个线程,在 Linux 中就会被视为是两个 CPU。按这种方式来使用这种类型的硬件的 SMT 处理器通常被称为 "siblings (兄弟处理器)"。操作系统基本上无法控制 SMT 处理器在这些执行上下文(execution context)之间应该如何分配资源。

SMT 的做法可以更好地利用处理器的资源。因为当某一个执行路径被卡住时(例如在等待内存返回数据),物理 CPU 就可以执行其他线程的指令了。然而,处理器中的线程数量虽然增加了一倍,但是通常并不会使其处理能力也增加一倍。两个线程都在共同分享着相同的资源,因此当系统处于低负载状态时,SMT 模式才是最有效的。因此,两个 SMT 线程的计算能力肯定比两个物理 CPU core 的计算能力要低。

计算能力既然是有下降的,那么这个下降的数值就应该要在 scheduler 中有所反映,但具体应该降低多少,是完全取决于不同工作场景下的负载的,所以内核需要使用一些启发式方法(heuristic)。Linux 对此进行建模的方法就是降低在同一个硬件上运行的第二个(及以下)CPU 线程的 CPU 优先级(优先级是用来调节 CPU 被选中从而运行下一个指定任务的可能性大小的)。

用户可以在 /sys/devices/system/cpu/cpuX/topology/core_cpus_list(其中 X 是系统中的 CPU 编号)中看到这个系统的拓扑信息中的同级 CPU。例如,在一个有 SMT 的 12 核系统中:

$cat /sys/devices/system/cpu/cpu0/topology/core_cpus_list
0,6

这个结果意味着用户可见的 CPU core 0 和 6 是 SMT 方式的 sibling,所以它们使用的是同一个硬件 core。

ASYM_PACKING

Asymmetric packing(调度器中所谓的 SD_ASYM_PACKING 方式)是 2010 年为 PowerPC 架构添加的一个功能。调度器可以利用这个机制来将任务转移到某些 CPU 上从而让其他 CPU 空闲,来获得更好的处理器性能。然后,繁忙的 CPU 就可以进入到较低的 SMT 模式(也就是运行较少的线程),从而让整体系统性能更高。PowerPC 的 SMT 模式文档中包括了一些例子。

ASYM_PACKING 模式已经经历过多次重构了,目前在 x86 和 PowerPC 上都可以支持。针对 x86 的支持也包括可以比其他 core 拥有更高的 CPU 频率,例如使用 Turbo Boost Max Technology (ITMT)3.0 功能的情况下。2016 年的 Linux Plumbers Conference 上的 ppt 更详细地解释了这项工作。

Mixing SMT and ASYM_PACKING

Neri 在一个有着三个不同的 CPU 优先级的系统上观察到了一些不合理的调度决策。这个系统中包含高性能 CPU core(英特尔酷睿)与其 SMT sibling,以及较低性能的 CPU core(英特尔 Atom)。在这种情况下,合理的调度方法(至少是对于某些工作负载下)是应该首先使用高性能 core(但不用相应的 SMT 副线程),然后再使用较低性能的 core,最后再用 SMT secondary core。但是实际上调度器会先把 task 交给高性能 core 及其 SMT sibling 上,让其他 core 空闲。结果就是这些 task 在争夺处理器资源,而那些独立的 CPU 仍然闲置。

为了理解这个问题,可以思考一下 Neri 的一个 patch 中提到的例子。想象一下,某个系统中有两个物理 CPU,具有不同的优先级,分别是 60 和 30。它们都有 SMT sibling core。内核代码中使用了 x86 支持代码中的一个方程式来计算分配 SMT 优先级:

smt_prio = prio * smp_num_siblings / i;

其中 smt_prio 是 effective priority,prio 是 CPU 的 original priority,smp_num_siblings 是每个 CPU 的 sibling 的数量(在 Neri 的例子中是 2),i 是分配给当前所关注的物理 CPU 的 sibling 的数量,从 1 开始。根据该公式,第一个 CPU 的主线程的计算出来的优先级是 120,而其 SMT 兄弟姐妹的计算出来的优先级是 60。对于第二个 CPU,主线程的优先级为 60,sibling 线程的优先级为 30。在这种情况下,SMT sibling 和性能较低的主线程的优先级就相等了。

Neri 想改变调度器的实现,希望在使用 SMT sibling CPU 之前,优先将任务分配给第二个(物理)CPU 的主线程。为此,他提议修改公式,使之除以 sibling 数量的平方:

smt_prio = prio * smp_num_siblings / (i*i);

在此情况下,第一个 CPU 的线程优先级将是 120 和 30;然后是第二个 CPU 的线程的 60 和 15。因此,task 就会被优先安排在两个主线程上。

当涉及到调度器的负载平衡决策时,具体来说在调度器决定将一个任务从一个 CPU 移到另一个 CPU 来进行系统负载平衡时,Neri 的 patch set 做出了另一个改动。在决定是否将一个任务从原 CPU 移动到新的 CPU 时,调度器会考虑目标 CPU 是否有 SMT sibling。如果没有的话,就可以把一个至少有两个繁忙线程的 SMT 原 CPU 的任务交给这个目标 CPU。如果原 CPU 中只有一个 sibling core 在忙,那么仅当目标 CPU 的优先级高于原 CPU 时,task 才会被迁移。

Summary

根据作者提供的基准测试结果,调度性能在某些情况下提高了几个百分点,尽管在大多数情况下提升比较小。基准测试也展示了一些情况下的性能有下降,但是 Neri 没有对这个结果做出解释。

这个改动已经被合并到 5.16 内核中,所以使用新 kernel 的系统的所有者应该可以观察到调度的变化,并希望能有更好的性能。这个改动修正了调度策略中的一个 corner case,很有可能这并不是唯一一个需要处理的 corner case。预期在未来应该能看到更多的关于 asymmetric CPU 的调度策略的调整。

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

欢迎分享、转载及基于现有协议再创作~

长按下面二维码关注,关注 LWN 深度文章以及开源社区的各种新近言论~

5e2dcb54f644155ff9fb27b97f75a411.png

这篇关于LWN:修复asymmetric CPU packing 中的小问题!的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/210681

相关文章

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

Java 线程安全与 volatile与单例模式问题及解决方案

《Java线程安全与volatile与单例模式问题及解决方案》文章主要讲解线程安全问题的五个成因(调度随机、变量修改、非原子操作、内存可见性、指令重排序)及解决方案,强调使用volatile关键字... 目录什么是线程安全线程安全问题的产生与解决方案线程的调度是随机的多个线程对同一个变量进行修改线程的修改操

Redis出现中文乱码的问题及解决

《Redis出现中文乱码的问题及解决》:本文主要介绍Redis出现中文乱码的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 问题的产生2China编程. 问题的解决redihttp://www.chinasem.cns数据进制问题的解决中文乱码问题解决总结

全面解析MySQL索引长度限制问题与解决方案

《全面解析MySQL索引长度限制问题与解决方案》MySQL对索引长度设限是为了保持高效的数据检索性能,这个限制不是MySQL的缺陷,而是数据库设计中的权衡结果,下面我们就来看看如何解决这一问题吧... 目录引言:为什么会有索引键长度问题?一、问题根源深度解析mysql索引长度限制原理实际场景示例二、五大解决

Springboot如何正确使用AOP问题

《Springboot如何正确使用AOP问题》:本文主要介绍Springboot如何正确使用AOP问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录​一、AOP概念二、切点表达式​execution表达式案例三、AOP通知四、springboot中使用AOP导出

Python中Tensorflow无法调用GPU问题的解决方法

《Python中Tensorflow无法调用GPU问题的解决方法》文章详解如何解决TensorFlow在Windows无法识别GPU的问题,需降级至2.10版本,安装匹配CUDA11.2和cuDNN... 当用以下代码查看GPU数量时,gpuspython返回的是一个空列表,说明tensorflow没有找到

解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题

《解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题》:本文主要介绍解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4... 目录未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘打开pom.XM

IDEA Maven提示:未解析的依赖项的问题及解决

《IDEAMaven提示:未解析的依赖项的问题及解决》:本文主要介绍IDEAMaven提示:未解析的依赖项的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录IDEA Maven提示:未解析的依编程赖项例如总结IDEA Maven提示:未解析的依赖项例如

Redis分片集群、数据读写规则问题小结

《Redis分片集群、数据读写规则问题小结》本文介绍了Redis分片集群的原理,通过数据分片和哈希槽机制解决单机内存限制与写瓶颈问题,实现分布式存储和高并发处理,但存在通信开销大、维护复杂及对事务支持... 目录一、分片集群解android决的问题二、分片集群图解 分片集群特征如何解决的上述问题?(与哨兵模

SpringBoot+Redis防止接口重复提交问题

《SpringBoot+Redis防止接口重复提交问题》:本文主要介绍SpringBoot+Redis防止接口重复提交问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不... 目录前言实现思路代码示例测试总结前言在项目的使用使用过程中,经常会出现某些操作在短时间内频繁提交。例