调度器 Nice 设计 【ChatGPT】

简介: 调度器 Nice 设计 【ChatGPT】

调度器 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 动态范围重新校准的自动副作用。

相关文章
|
2月前
|
缓存 Linux 调度
调度器统计 【ChatGPT】
调度器统计 【ChatGPT】
|
2月前
|
调度
调度器调试文件说明 【ChatGPT】
调度器调试文件说明 【ChatGPT】
|
2月前
|
调度
CPU调度器实现提示:针对特定体系结构代码【ChatGPT】
CPU调度器实现提示:针对特定体系结构代码【ChatGPT】
|
2月前
|
缓存 负载均衡 算法
CFS调度器 【ChatGPT】
CFS调度器 【ChatGPT】
|
3月前
|
人工智能 自然语言处理 搜索推荐
chatgpt这么火,现在AI搜索引擎有哪些呢?
国外AI搜索引擎包括ChatGPT,擅长自然语言处理与内容生成;Google Bard,提供智能个性化搜索体验;Microsoft Bing集成GPT模型增强智能检索;Perplexity AI以简洁答案及文献引用著称;Neeva强调隐私保护与无广告服务。国内方面,天工AI支持多种功能如知识问答与代码编程;腾讯元宝基于混元模型助力内容创造与学习;360AI搜索以精准全面的信息搜索见长;秘塔AI专注提升写作质量和效率;开搜AI搜索提供个性化智能搜索服务。以上引擎均利用先进AI技术提升用户体验。更多详情参阅[AI搜索合集](zhangfeidezhu.com/?page_id=651)。
109 8
chatgpt这么火,现在AI搜索引擎有哪些呢?
|
3月前
|
机器学习/深度学习 人工智能 自然语言处理
HuggingGPT解析:使用 ChatGPT及HuggingFace上的族系解决AI问题
HuggingGPT是一个框架,它使用大型语言模型(如ChatGPT)作为控制器来管理和协调Hugging Face上的AI模型,以语言作为通用接口解决多模态和领域的复杂AI任务。
56 0
HuggingGPT解析:使用 ChatGPT及HuggingFace上的族系解决AI问题
|
3月前
|
机器学习/深度学习 人工智能 算法
为什么ChatGPT等AI大模型都是基于Python开发?
为什么ChatGPT等AI大模型都是基于Python开发?
|
3月前
|
人工智能 自然语言处理 Linux
免费ChatGPT4o灵办AI可体验浏览器插件
灵办AI就是您所需的最佳助手!我们为您带来了一款多功能AI工具,ChatGPT4o不仅能为您提供精准翻译,还能满足您的对话需求、智能续写、AI搜索、文档阅读、代码生成与修正等多种需求。灵办 AI,真正让工作和学习变得轻松高效!一款多功能智能助手,旨在提升工作和学习效率。它提供实时翻译、对话问答、搜索、写作和网页阅读等服务,支持多种浏览器和操作系统,帮助用户随时获取信息,打破语言障碍,优化内容创作和信息处理。
114 0
|
3月前
|
Web App开发 人工智能 安全
Gemini vs ChatGPT:谷歌最新的AI和ChatGPT相比,谁更强?
Gemini vs ChatGPT:谷歌最新的AI和ChatGPT相比,谁更强?
|
3月前
|
人工智能 安全 机器人
ChatGPT 1岁:创新、争议和AI产生突破的一年
ChatGPT 1岁:创新、争议和AI产生突破的一年