首页 > 其他分享 >调度器 Nice 设计 【ChatGPT】

调度器 Nice 设计 【ChatGPT】

时间:2023-12-11 21:57:27浏览次数:33  
标签:level 19 调度 levels ChatGPT Nice CPU nice

调度器 Nice 设计

本文档解释了在新的 Linux 调度器中重新设计和简化 nice-levels 实现的思路。

在 Linux 下,nice levels 一直比较弱,人们不断地纠缠我们,希望让 nice +19 的任务使用更少的 CPU 时间。

不幸的是,在旧的调度器下实现这一点并不容易(否则我们早就做了),因为 nice level 的支持历来与时间片长度耦合,而时间片单位由 HZ tick 驱动,因此最小的时间片是 1/HZ。

在 O(1) 调度器中(2003 年),我们将负 nice levels 设计得比 2.4 版本中更强(人们对这一变化感到满意),并且故意校准了线性时间片规则,使得 nice +19 级别的任务的时间片长度恰好为 1 个 jiffy。为了更好地理解,时间片图如下所示:

                  A
            \     | [时间片长度]
             \    |
              \   |
               \  |
                \ |
                 \|___100毫秒
                  |^ . _
                  |      ^ . _
                  |            ^ . _
-*----------------------------------*-----> [nice level]
-20               |                +19
                  |
                  |

因此,如果有人真的想要调整任务的优先级,+19 将比正常的线性规则产生更大的影响。(改变 ABI 以扩展优先级的解决方案很快被放弃。)

这种方法在一定程度上起作用,但随着 HZ=1000,1 个 jiffy 变成了 1 毫秒,这意味着 0.1% 的 CPU 使用率,这被认为有点过高。过高不是因为 CPU 利用率太低,而是因为导致过于频繁(每毫秒一次)的重新调度。(这样会破坏缓存等。请记住,这是很久以前,硬件性能较弱,缓存较小,人们在 nice +19 下运行数值计算应用。)

因此,对于 HZ=1000,我们将 nice +19 调整为 5 毫秒,因为这样感觉上是正确的最小粒度,这相当于 5% 的 CPU 使用率。但 nice+19 的基本 HZ 敏感属性仍然存在,我们从来没有收到过有关 nice +19 在 CPU 利用率方面过于“弱”的投诉,我们只收到过有关它(仍然)过于“强”的投诉。

总之,我们一直希望使 nice levels 更一致,但在 HZ 和 jiffies 的约束下,以及它们与时间片和粒度的恶劣设计级耦合的情况下,这并不是真正可行的。

第二个(不太频繁但仍然定期出现的)关于 Linux nice level 支持的投诉是其在原点周围的不对称性(可以在上面的图片中看到),更准确地说:nice level 行为也取决于绝对 nice level,而 nice API 本身基本上是“相对”的:

int nice(int inc);

asmlinkage long sys_nice(int increment)

(第一个是 glibc API,第二个是系统调用 API。)请注意,'inc' 是相对于当前 nice level 的。像 bash 的 "nice" 命令这样的工具反映了这种相对 API。

在旧的调度器中,例如,如果您启动了一个 nice +1 的任务和另一个 nice +2 的任务,这两个任务之间的 CPU 分配将取决于父 shell 的 nice level - 如果它是 nice -10,CPU 分配将与它是 +5 或 +10 时不同。

对 Linux nice level 支持的第三个投诉是负 nice levels 不够“强烈”,因此很多人不得不将音频(和其他多媒体)应用程序强制运行在 SCHED_FIFO 等更危险的实时优先级下。但这会带来其他问题:SCHED_FIFO 不能防止饥饿,而且有 bug 的 SCHED_FIFO 应用程序也可能永久锁定系统。

v2.6.23 中的新调度器解决了这三种类型的投诉:

为了解决第一个投诉(nice levels 不够“强烈”),调度器与“时间片”和 HZ 概念解耦(并且粒度被作为与 nice levels 分离的概念),因此可以更好地实现更一致的 nice +19 支持:在新的调度器中,nice +19 任务获得了与 HZ 无关的 1.5% 的 CPU 利用率,而不是在旧调度器中的 3%-5%-9% 范围内。

为了解决第二个投诉(nice levels 不一致),新的调度器使 nice(1) 对任务具有相同的 CPU 利用效果,而不考虑它们的绝对 nice levels。因此,在新的调度器中,运行一个 nice +10 任务和一个 nice 11 任务的 CPU 利用率“分配”效果与运行一个 nice -5 任务和一个 nice -4 任务的效果相同(一个将获得 55% 的 CPU,另一个将获得 45%)。这就是为什么 nice levels 被改为“乘法”(或指数)的原因,这样无论你从哪个 nice level 开始,相对结果都是相同的。

第三个投诉(负 nice levels 不够“强烈”并且迫使音频应用在更危险的 SCHED_FIFO 调度策略下运行)几乎自动地被新的调度器解决了:更强的负 nice levels 是 nice levels 动态范围重新校准的自动副作用。

标签:level,19,调度,levels,ChatGPT,Nice,CPU,nice
From: https://www.cnblogs.com/pengdonglin137/p/17895652.html

相关文章

  • 实时组调度 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/sched-rt-group.html实时组调度0.警告调整这些设置可能导致系统不稳定,这些旋钮只有root用户才能操作,并且假设root用户知道自己在做什么。最值得注意的是:在sched_rt_period_us中使用非常小的值可能导致系统不稳定,......
  • 利用率夹紧(Utilization Clamping) 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/sched-util-clamp.html利用率夹紧1.简介利用率夹紧,也称为utilclamp或uclamp,是一种调度器功能,允许用户空间帮助管理任务的性能需求。它是在v5.3版本中引入的。CGroup支持在v5.4中合并。Uclamp是一种提示机制,允许调度器了解......
  • 能量感知调度(EAS) 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/sched-energy.html能量感知调度1.简介能量感知调度(EnergyAwareScheduling,EAS)赋予调度器预测其决策对CPU能量消耗的影响的能力。EAS依赖于CPU的能量模型(EnergyModel,EM)来为每个任务选择一个能效高、对吞吐量影响最小......
  • Schedutil 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/schedutil.htmlSchedutil注意所有这些都假设频率和工作能力之间存在线性关系,我们知道这是有缺陷的,但这是最好的可行近似。PELT(PerEntityLoadTracking)使用PELT,我们跟踪各种调度实体的一些指标,从单个任务到任务组切片到......
  • 容量感知调度 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/sched-capacity.html容量感知调度1.CPU容量1.1简介传统的同质SMP平台由纯粹相同的CPU组成。另一方面,异构平台由具有不同性能特征的CPU组成-在这样的平台上,并非所有CPU都可以被视为相等。CPU容量是衡量CPU可......
  • Completions - "wait for completion" barrier APIs 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/completion.htmlCompletions-"waitforcompletion"barrierAPIs介绍:如果您有一个或多个线程必须等待某些内核活动达到某个点或特定状态,完成(completions)可以为这个问题提供无竞争的解决方案。从语义上讲,它们有点像pthread......
  • CFS调度器 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/sched-design-CFS.htmlCFS调度器1.概述CFS代表“完全公平调度器”,是由IngoMolnar实现并合并到Linux2.6.23中的新“桌面”进程调度器。它是替代先前普通调度器SCHED_OTHER交互代码的调度器。CFS设计的80%可以用一句话概括......
  • 调度器域 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/sched-domains.html调度器域每个CPU都有一个“基本”调度域(structsched_domain)。域层次结构是通过这些基本域通过->parent指针构建的。->parent必须以NULL结尾,并且域结构应该是每个CPU的,因为它们是无锁更新的。每......
  • xx 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/scheduler/sched-bwc.htmlCFS带宽控制注意本文仅讨论SCHED_NORMAL的CPU带宽控制。SCHED_RT情况在实时组调度中有所涉及。CFS带宽控制是CONFIG_FAIR_GROUP_SCHED的扩展,它允许指定组或层次结构可用的最大CPU带宽。为组允许的带宽使用......
  • 远程处理器框架 【ChatGPT】
    https://www.kernel.org/doc/html/v6.6/staging/remoteproc.html#remote-processor-framework远程处理器框架简介现代SoC通常具有异构的远程处理器设备,采用非对称多处理(AMP)配置,可以运行不同实例的操作系统,无论是Linux还是任何其他实时操作系统的变种。例如,OMAP4具有双核Cort......