当前位置:首页 > 嵌入式 > Linux阅码场
[导读]编者按:CPUBurst特性已合入Linux5.14,AnolisOS8.2、AlibabaCloudLinux2、AlibabaCloudLinux3也都支持CPUBurst特性。在系列文章的上篇中,我们讨论了让人讨厌的CPU限流,它会影响运行在容器中的应用的一些关键指标。为了...

编者按:CPU Burst 特性已合入 Linux 5.14,Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3也都支持CPU Burst特性。


在系列文章的上篇中,我们讨论了让人讨厌的 CPU 限流,它会影响运行在容器中的应用的一些关键指标。为了避免限流的出现,有时我们不得不牺牲容器部署密度,从而导致资源浪费的产生。在解决方案部分,我们也介绍了新的CPU Burst 技术,通过这一技术,我们既能保证容器运行服务质量,又不降低容器部署密度。听起来有点像个银弹啊?那么,使用CPU Burst的副作用是什么?是否有不适用的场景呢?为了回答这个问题,本文将介绍CPU Burst打破的调度保证,以及CPU Burst影响评估。尽管这些CPU突发的使用造成的CPU使用差异在CPU利用率上很多时候不明显,但是我们仍然关心这种改变的影响。当然,结论是明确的:CPU Burst的负面影响完全可以忽略。仅在CPU利用率高达70%的环境里CPU Burst开始影响关键指标,而我相信大家日常生产环境的CPU利用率都远远低于这个水平。
CPU Bandwidth Controller的保证
使用CPU Bandwidth Controller可以避免某些进程消耗过多CPU时间,并确保所有需要CPU的进程都拿到足够的CPU时间。之所以有这样好的稳定性保证,是因为当Bandwidth Controller设置满足时,有如下的调度稳定性约束:



其中是第i个cgroup的quota,是一个period内该cgroup的CPU需求。Bandwidth Controller对每个周期分别做CPU时间统计,调度稳定性约束保证在一个period内提交的全部任务都能在该周期内处理完;对每个CPU cgroup而言,这意味着任何时候提交的任务都能在一个period内执行完,即任务实时性约束:


不管任务优先级如何,最坏情况下任务执行时间(WCET, Worst-Case Execution Time)不超过一个period。假如持续出现调度器稳定性被打破,在每个period都有任务积攒下来,新提交的作业执行时间不断增加。


使用CPU Burst的影响
出于改善服务质量的需要,我们使用CPU Burst允许突发的CPU使用之后,对调度器的稳定性产生什么影响?答案是当多个cgroup同时突发使用CPU,调度器稳定性约束和任务实时性保证有可能被打破。这时候两个约束得到保证的概率是关键,如果两个约束得到保证的概率很高,对大多数周期来任务实时性都得到保证,可以放心大胆使用CPU Burst;如果任务实时性得到保证的概率很低,这时候要改善服务质量不能直接使用CPU Burst,应该先降低部署密度提高CPU资源配置。于是下一个关心的问题是,怎么计算特定场景下两个约束被打破的概率。
评估影响大小
定量计算可以定义成经典的排队论问题,并且用蒙特卡洛模拟方法求解。定量计算的结果表明,判断当前场景是否可以使用CPU Burst的主要影响因素是平均CPU利用率和cgroup数目。CPU利用率越低,或者cgroup数目越多,两个约束越不容易被打破可以放心使用CPU Burst。反之如果CPU利用率很高或者cgroup数目较少,要消除CPU限流对进程执行的影响,应该降低部署提高配置再使用CPU Burst。问题定义是:一共有m个cgroup,每个cgroup的quota限制为1/m,每个cgroup在每个周期产生的计算需求(CPU利用率)服从某个具体分布,这些分布是相互独立的。假设任务在每个周期的开始到达,如果该周期内的CPU需求超过100%,当前周期任务WCET超过1个period,超过的部分累积下来和下个周期新产生的CPU需求一起在下个需求处理。输入是cgroup的数目m和每个CPU需求满足的具体分布,输出是每个周期结束WCET > period的概率和WCET期望。使用蒙特卡洛模拟求解过程省略,详细请关注后续系列文章。以输入的CPU需求为帕累托分布、m=10/20/30的结果为例进行说明。选择帕累托分布进行说明的原因是它产生比较多的长尾CPU突发使用,容易产生较大影响。表格中数据项的格式为,其中越接近1越好,概率越低越好。
u_avg


m=10


m=20


m=30



10%


1.0000/0.00%


1.0000/0.00%


1.0000/0.00%


30%


1.0000/0.00% 1.0000/0.00% 1.0000/0.00%


50%


1.0003/0.03% 1.0000/0.00% 1.0000/0.00%


70%


1.0077/0.66% 1.0013/0.12% 1.0004/0.04%


90%


1.4061/19.35% 1.1626/10.61% 1.0867/6.52%
结果跟直觉是吻合的。一方面,CPU需求(CPU利用率)越高,CPU突发越容易打破稳定性约束,造成任务WCET期望变长。另一方面,CPU需求独立分布的cgroup数目越多,它们同时产生CPU突发需求的可能性越低,调度器稳定性约束越容易保持,WCET的期望越接近1个period。


后续
看完本文相信您对CPU Burst的影响已经有了定性了解。如果希望对评估方法有更多了解,请期待系列文章的下篇。关于作者


常怀鑫(一斋),阿里云内核组工程师,擅长CPU调度领域。


丁天琛(鹰羽),2021年加入阿里云内核组,目前在调度领域等方面学习研究——完——




本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除( 邮箱:macysun@21ic.com )。
换一批
延伸阅读

不少团队把应用切成容器后,以为节点上线会更灵活。边缘计算真到现场时,最先暴露的往往不是编排能力,而是冷启动被镜像拉取和层展开拖得过长。

关键字: 边缘计算 冷启动 CPU

在现代多核CPU的高并发编程领域,Cache伪共享是最隐蔽也最容易被忽略的性能杀手,结合我们之前深入探讨过的C++内存模型、无锁队列实现、Mutex互斥锁优化等工程实践经验,很多开发者在编写高并发多线程代码时,明明逻辑上...

关键字: CPU 伪共享

在电力电子系统全面转向数字化的当下,很多工程师都会遇到一个看似矛盾的现象:明明选用了主频足够高的数字信号控制器,算法逻辑也经过反复验证没有问题,但最终整机的稳态精度和动态性能,始终达不到理论仿真的预期。反复排查软件逻辑后...

关键字: 数字控制 CPU

机器人产业的真正分水岭,可能既不在算力大小,也不在模型参数的多寡。在各类人形机器人、自主移动机器人与智能工业系统密集亮相的当下,一个更本质的问题正在被反复追问:一台已经掌握多项技能的机器人,为什么换一个场景、换一个任务,...

关键字: ARM 物理 AI 机器人 泛化能力 CPU 运动控制

微软和亚马逊云科技最新财报传递出同一个信号:基于 Arm 架构的 CPU 已成为智能体 AI 的核心基础设施。

关键字: 云计算 CPU AI

很多现场节点一遇到吞吐瓶颈,就想把内存复制次数砍掉。边缘计算若把零拷贝只当成省一次 memcpy,很容易把新的时延和一致性问题带进主链路。

关键字: 边缘计算 零拷贝 CPU

我们已经过了仅凭演示效果来评判人工智能 (AI) 基础设施的阶段。如今,更关键的问题在于,这些能力能否以可靠、可扩展且具备成本效益的方式交付。这正是我们在设计下一代 AI 基础设施过程中,与云服务提供商、芯片合作伙伴及系...

关键字: 人工智能 CPU 自研芯片

如果我们用Arduino核心在ESP8266上写任何代码,很可能已经遇到了这个瓶颈。你写的每一行代码都运行在loop()函数内部,而loop()是协作式的——它从上到下依次执行,只有在完成所有操作后,SDK才会有机会进行...

关键字: Arduino CPU LED ESP8266

本项目记录了将一块基于STM32F407的空开发板,通过将其内部12位数模转换器(DAC)连接至PA4引脚,成功改造为功能完整的模拟信号发生器的过程。从完全零基础构建的裸机模板出发,在调试固件配置方面积累了极为丰富的学习...

关键字: CPU 信号发生器 定时器 STM32F407

核心数量提升33%、PCIe带宽提升至2倍、内存带宽提升至2.6倍,大幅强化高性能工作负载的运行。 搭载第六代AMD EPYC CPU和AMD Instinct™...

关键字: AMD CPU MICRO SUPER
关闭