写点什么

CPU 隔离:管理和权衡

  • 2022 年 4 月 06 日
  • 本文字数:1784 字

    阅读完需:约 6 分钟

CPU 隔离:管理和权衡

SUSE Labs 团队探索了 Kernel CPU 隔离及其核心组件之一:Full Dynticks(或 Nohz Full),并撰写了本系列文章:

 

1. CPU 隔离 – 简介

2. CPU 隔离 – Full Dynticks 深探

3. CPU 隔离 – Nohz_full

4. CPU 隔离 – 管理和权衡

5. CPU 隔离 – 实践

 

本文是第四篇。

 

CPU 隔离和 nohz_full 用户需要了解的基本原则:干扰很少能被消除,而是转移到其他地方。

管理


我们之前曾简要解释过,内务管理是内核需要做的周期性工作或事件驱动的基础工作,目的是维护其内部状态和服务,例如更新调度程序的内部统计数据或计时。

 

在正常的配置下,每个 CPU 都要承担内务管理工作。相反,nohz_full 配置会以隐含方式移除 nohz_full 集合之外的所有的内务管理工作。

 

也就是说,如果您有 8 个 CPU,并隔离 CPU 1、2、3、4、5、6、7:

 

nohz_full=1-7


则 CPU 0 将单独处理内务管理工作。这些工作涉及:

 

  • 未绑定计时器回调执行

  • 未绑定工作队列执行

  • 未绑定 kthreads 执行

  • 计时更新(jiffies 和 gettimeofday())

  • RCU 缓冲期跟踪

  • 代替隔离的 CPU 进行 RCU 回调执行

  • 代替隔离的 CPU 执行 1Hz 残余的已卸载计时器 Tick

  • 根据您的扩展设置:

  • 可以绑定的硬件 IRQ

  • 除隔离的工作负载以外的用户任务


尽管这些项目通常可由一个 CPU 代替其他 7 个 CPU 处理,但这种布局并不趋于无穷尽。随着 CPU 数量的增加,同时,随着内存和缓存的进一步分区,内务管理任务可能需要共担。通常情况下,为每个 NUMA 节点配置一个管理 CPU 是一种不错的方法。如以下配置所示:



由于 CPU 0 - 7 属于节点 0,CPU 8 - 15 属于节点 1,默认设置如下所示:

nohz_full=1-7,9-15


在测试阶段,建议通过 top/htop 等工具检查和监控管理程序的活动,以确保它们没有超负荷。例如,如果以上设置显示 CPU 0 或 CPU 8 的负荷为 100%,则可能需要添加更多的管理 CPU,尽管这种情况更有可能使用更多的节点来处理。

 

同样需要注意的是,对内核的访问(例如系统调用或内存故障)可能会产生更多的内务管理活动,并导致 CPU 承担更多负载。通常不建议从隔离的 CPU 中请求内核服务,这一点我们将在下一章介绍。

 

在任何情况下,内核都有内务工作需要处理,这不能忽略。如果所有 CPU 都被传递到“nohz_full=” 内核参数,则 CPU 0 将从隔离集合内随意清理出来,并为其单独分配内务管理工作,使用的消息如下:

NO_HZ: Clearing 0 from nohz_full range for timekeeping

 

因此,要注意的是:被隔离的 CPU 之所以获得无抖动的特性,是因为其他 CPU 承担了更多工作,而至少一个 CPU 需要为这些工作做出牺牲。

 

然而,这种情况并非一成不变。从长远来看,我们可以安排在隔离模式下运行所有 CPU,前提是在内核进入时更新计时,并且调度程序的能力进一步增强,能够支持在用户空间中运行长时间的任务,而不需要远程中断才能保持统计信息的最新状态。但我们还没有做到。

内核进入/退出的开销


完全的 dynticks 模式增加了内核进入和退出的大量开销。这些是由于:

 

  • 系统调用

  • 异常(页面错误、陷阱等)

  • 中断

 

这些开销首先是由于 RCU 跟踪和排序造成的。这项工作通常由周期性计时器中断来处理。现在,我们已经摒弃了这种方法,最终需要使用代价高昂的完全排序后的原子操作,来计算通过内核边界的往返次数。

 

这些开销的第二部分来自记录CPU运行时间。同样,内核必须使用内核边界上的探测器来计算任务在内核和用户空间中执行所花费的时间,因为周期性的中断不再执行这项工作。尽管记录 CPU 运行时间使用的排序比 RCU 跟踪要弱,但仍有一些处理会增加总体开销。


我们之前曾经说过,IRQ 与内务管理密切相关。使用 mlock() 可以防止页面错误(https://man7.org/linux/man-pages/man2/mlockall.2.html)。之后,用户需要减少系统调用,这就形成了一条硬性规则:full dynticks 不适合基于内核的 I/O 型工作负载。相反,应将其保留给以下任一方:

 

  • CPU 计算型的工作负载。涉及大量 CPU 处理和最少的基于内核的 I/O 的操作(依赖内核驱动程序处理系统调用和中断)。

  • 对于内核不参与的 I/O 类型的工作负载,即基于 DPDK 等用户空间驱动程序的 I/O (https://www.dpdk.org/)。

结语


CPU 隔离和 full dynticks 可以为某些特定工作负载带来明显好处,但需注意,它在许多情况下并不适用。您必须特别注意以下两点:

 

  • 您需要牺牲一个隔离的 CPU,由其处理内核内部的无聊工作。

  • Full dynticks 仅适用于 CPU 计算型的工作负载,或者基于用户空间驱动程序的 I/O。


在第五篇文章中,我们将最终测试这一特性,并展示如何识别并调试其余的干扰。

2022 年 4 月 06 日 11:431019

评论

发布
暂无评论
发现更多内容

Android 文件重定向下载 & 通知问题小结

阿策小和尚

28天写作 Android 小菜鸟 12月日更

微信小程序开发:如何快速实现分割线的项目需求

三掌柜

28天写作 12月日更 12月

瞰见 | 黯然退市的 Cloudera, 让我们开源人情何以堪?

OpenTEKr

狄安瞰源

我可能误会了理性的作用

Justin

心理学 创意 理性 28天写作

100% 展示 MySQL 语句执行的神器-Optimizer Trace

程序员历小冰

MySQL 28天写作 12月日更

拿它们练Python爬虫,是在法律边缘试探吗?爬虫圈香饽饽之视频网站的评论区采集

梦想橡皮擦

12月日更

给弟弟的信第10封|但行好事,莫问前程

大菠萝

28天写作

「如何从零到一实现一个玩具浏览器🌏」

速冻鱼

前端 浏览器 签约计划第二季 12月日更

团队基建系列 - 组织知识传承 6 成功要素

Hillz

团队文化 团队成长

Zilliz 顾钧:开源是协调技术供应商、开发者和用户之间利益的一种更健康的方式 I OpenTEKr 大话开源 Vol.2

OpenTEKr

大话开源

高效的部署微服务

卢卡多多

28天写作 12月日更

毕业设计

4anonymous

元宇宙100讲--0x001

hackstoic

元宇宙

模块六

小何

「架构实战营」

微信朋友圈高性能复杂度分析

drizzle

「架构实战营」

Tracking & Being

mtfelix

28天写作

Eureka非分区集群部署

李子捌

微服务 28天写作 12月日更

电商秒杀架构设计

George

架构学习总结

George

【LeetCode】最小基因变化Java题解

Albert

算法 LeetCode 12月日更

Vue进阶(幺贰玖):初探 Vue3

No Silver Bullet

Vue3 12月日更

模块六作业:拆分电商系统为微服务

危险游戏

架构实战营

【Java技术开发专题】系列之「Guava RateLimiter」针对于限流器的入门到实战(含源码分析介绍)

浩宇の天尚

ratelimiter Guava 限流器 RateLimit 12月日更

数据大体系(二)——数仓的一般命名规范

圣迪

大数据 数仓 命名

工作到退休,会是什么样子的?(11/28)

赵新龙

28天写作

毕业总结

4anonymous

刷新

Nydia

[Pulsar] 一个消息的生命历程

Zike Yang

Apache Pulsar 12月日更

如何够量-训练你的主题演讲

将军-技术演讲力教练

前端开发:运行npm install 提示XXX packages are looking for funding run `npm fund`的解决方法

三掌柜

28天写作 21天挑战 12月日更 12月

volatile 为什么不保证原子性

悟空聊架构

volatile 原子性 28天写作 悟空聊架构 12月日更

金融行业数据库架构实践与运维

金融行业数据库架构实践与运维

CPU 隔离:管理和权衡_硬件_Frederic Weisbecker_InfoQ精选文章