1
linux/Documentation/translations/zh_CN/scheduler/sched-nice-design.rst
Tang Yizhou c01c2e435d docs/zh_CN: Add sched-nice-design Chinese translation
Translate scheduler/sched-nice-design.rst into Chinese.

Signed-off-by: Tang Yizhou <tangyizhou@huawei.com>
Reviewed-by: Yanteng Si <siyanteng@loongson.cn>
Reviewed-by: Alex Shi <alexs@kernel.org>
Link: https://lore.kernel.org/r/20220312072642.23118-1-tangyizhou@huawei.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2022-03-16 15:49:57 -06:00

100 lines
5.1 KiB
ReStructuredText
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/scheduler/sched-nice-design.rst
:翻译:
唐艺舟 Tang Yizhou <tangyeechou@gmail.com>
=====================
调度器nice值设计
=====================
本文档解释了新的Linux调度器中修改和精简后的nice级别的实现思路。
Linux的nice级别总是非常脆弱人们持续不断地缠着我们让nice +19的任务占用
更少的CPU时间。
不幸的是,在旧的调度器中,这不是那么容易实现的(否则我们早就做到了),因为对
nice级别的支持在历史上是与时间片长度耦合的而时间片单位是由HZ滴答驱动的
所以最小的时间片是1/HZ。
在O(1)调度器中2003年我们改变了负的nice级别使它们比2.4内核更强
人们对这一变化很满意而且我们还故意校正了线性时间片准则使得nice +19
的级别 _正好_ 是1 jiffy。为了让大家更好地理解它时间片的图会是这样的质量
不佳的ASCII艺术提醒::
A
\ | [timeslice length]
\ |
\ |
\ |
\ |
\|___100msecs
|^ . _
| ^ . _
| ^ . _
-*----------------------------------*-----> [nice level]
-20 | +19
|
|
因此如果有人真的想renice任务相较线性规则+19会给出更大的效果改变
ABI来扩展优先级的解决方案在早期就被放弃了
这种方法在一定程度上奏效了一段时间但后来HZ=1000时它导致1 jiffy为
1ms这意味着0.1%的CPU使用率我们认为这有点过度。过度 _不是_ 因为它表示
的CPU使用率过小而是因为它引发了过于频繁每毫秒1次的重新调度因此会
破坏缓存等等。请记住硬件更弱、cache更小是很久以前的事了当时人们在
nice +19级别运行数量颇多的应用程序
因此对于HZ=1000我们将nice +19改为5毫秒因为这感觉像是正确的最小
粒度——这相当于5%的CPU利用率。但nice +19的根本的HZ敏感属性依然保持不变
我们没有收到过关于nice +19在CPU利用率方面太 _弱_ 的任何抱怨,我们只收到
过它(依然)太 _强_ 的抱怨 :-)。
总结一下我们一直想让nice各级别一致性更强但在HZ和jiffies的限制下以及
nice级别与时间片、调度粒度耦合是令人讨厌的设计这一目标并不真正可行。
第二个关于Linux nice级别支持的抱怨是不那么频繁但仍然定期发生
在原点周围的不对称性(你可以在上面的图片中看到),或者更准确地说:事实上
nice级别的行为取决于 _绝对的_ nice级别而nice应用程序接口本身从根本上
说是“相对”的:
int nice(int inc);
asmlinkage long sys_nice(int increment)
第一个是glibc的应用程序接口第二个是syscall的应用程序接口
注意“inc”是相对当前nice级别而言的类似bash的“nice”命令等工具是这个
相对性应用程序接口的镜像。
在旧的调度器中举例来说如果你以nice +1启动一个任务并以nice +2启动
另一个任务这两个任务的CPU分配将取决于父外壳程序的nice级别——如果它是
nice -10那么CPU的分配不同于+5或+10。
第三个关于Linux nice级别支持的抱怨是负数nice级别“不够有力”以很多人
不得不诉诸于实时调度优先级来运行音频(和其它多媒体)应用程序,比如
SCHED_FIFO。但这也造成了其它问题SCHED_FIFO未被证明是免于饥饿的一个
有问题的SCHED_FIFO应用程序也会锁住运行良好的系统。
v2.6.23版内核的新调度器解决了这三种类型的抱怨:
为了解决第一个抱怨nice级别不够“有力”调度器与“时间片”、HZ的概念
解耦调度粒度被处理成一个和nice级别独立的概念因此有可能实现更好、
更一致的nice +19支持在新的调度器中nice +19的任务得到一个HZ无关的
1.5%CPU使用率而不是旧版调度器中3%-5%-9%的可变范围。
为了解决第二个抱怨nice各级别不一致新调度器令调用nice(1)对各任务的
CPU利用率有相同的影响无论其绝对nice级别如何。所以在新调度器上运行一个
nice +10和一个nice +11的任务会与运行一个nice -5和一个nice -4的任务的
CPU利用率分割是相同的一个会得到55%的CPU另一个会得到45%)。这是为什么
nice级别被改为“乘法”或指数——这样的话不管你从哪个级别开始“相对”
结果将总是一样的。
第三个抱怨负数nice级别不够“有力”并迫使音频应用程序在更危险的
SCHED_FIFO调度策略下运行几乎被新的调度器自动解决了更强的负数级别
具有重新校正nice级别动态范围的自动化副作用。