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

相关文章

大数据小内存排序问题如何巧妙解决

《大数据小内存排序问题如何巧妙解决》文章介绍了大数据小内存排序的三种方法:数据库排序、分治法和位图法,数据库排序简单但速度慢,对设备要求高;分治法高效但实现复杂;位图法可读性差,但存储空间受限... 目录三种方法:方法概要数据库排序(http://www.chinasem.cn对数据库设备要求较高)分治法(常

Vue项目中Element UI组件未注册的问题原因及解决方法

《Vue项目中ElementUI组件未注册的问题原因及解决方法》在Vue项目中使用ElementUI组件库时,开发者可能会遇到一些常见问题,例如组件未正确注册导致的警告或错误,本文将详细探讨这些问题... 目录引言一、问题背景1.1 错误信息分析1.2 问题原因二、解决方法2.1 全局引入 Element

关于@MapperScan和@ComponentScan的使用问题

《关于@MapperScan和@ComponentScan的使用问题》文章介绍了在使用`@MapperScan`和`@ComponentScan`时可能会遇到的包扫描冲突问题,并提供了解决方法,同时,... 目录@MapperScan和@ComponentScan的使用问题报错如下原因解决办法课外拓展总结@

MybatisGenerator文件生成不出对应文件的问题

《MybatisGenerator文件生成不出对应文件的问题》本文介绍了使用MybatisGenerator生成文件时遇到的问题及解决方法,主要步骤包括检查目标表是否存在、是否能连接到数据库、配置生成... 目录MyBATisGenerator 文件生成不出对应文件先在项目结构里引入“targetProje

C#使用HttpClient进行Post请求出现超时问题的解决及优化

《C#使用HttpClient进行Post请求出现超时问题的解决及优化》最近我的控制台程序发现有时候总是出现请求超时等问题,通常好几分钟最多只有3-4个请求,在使用apipost发现并发10个5分钟也... 目录优化结论单例HttpClient连接池耗尽和并发并发异步最终优化后优化结论我直接上优化结论吧,

Java内存泄漏问题的排查、优化与最佳实践

《Java内存泄漏问题的排查、优化与最佳实践》在Java开发中,内存泄漏是一个常见且令人头疼的问题,内存泄漏指的是程序在运行过程中,已经不再使用的对象没有被及时释放,从而导致内存占用不断增加,最终... 目录引言1. 什么是内存泄漏?常见的内存泄漏情况2. 如何排查 Java 中的内存泄漏?2.1 使用 J

numpy求解线性代数相关问题

《numpy求解线性代数相关问题》本文主要介绍了numpy求解线性代数相关问题,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧... 在numpy中有numpy.array类型和numpy.mat类型,前者是数组类型,后者是矩阵类型。数组

解决systemctl reload nginx重启Nginx服务报错:Job for nginx.service invalid问题

《解决systemctlreloadnginx重启Nginx服务报错:Jobfornginx.serviceinvalid问题》文章描述了通过`systemctlstatusnginx.se... 目录systemctl reload nginx重启Nginx服务报错:Job for nginx.javas

Redis缓存问题与缓存更新机制详解

《Redis缓存问题与缓存更新机制详解》本文主要介绍了缓存问题及其解决方案,包括缓存穿透、缓存击穿、缓存雪崩等问题的成因以及相应的预防和解决方法,同时,还详细探讨了缓存更新机制,包括不同情况下的缓存更... 目录一、缓存问题1.1 缓存穿透1.1.1 问题来源1.1.2 解决方案1.2 缓存击穿1.2.1

vue解决子组件样式覆盖问题scoped deep

《vue解决子组件样式覆盖问题scopeddeep》文章主要介绍了在Vue项目中处理全局样式和局部样式的方法,包括使用scoped属性和深度选择器(/deep/)来覆盖子组件的样式,作者建议所有组件... 目录前言scoped分析deep分析使用总结所有组件必须加scoped父组件覆盖子组件使用deep前言