Documentation_scheduler_sched-nice-design

Chinese translated version of Documentation/scheduler/sched-nice-design

Documentation/scheduler/sched-nice-design 的中文翻译

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

 

中文版维护者： 潘丽卡  774945605@qq.com
中文版翻译者： 潘丽卡  774945605@qq.com
中文版校译者： 黄佳露  799942107@qq.com
Chinese maintainer: 774945605@qq.com
---------------------------------------------------------------------

 

 

以下为正文
---------------------------------------------------------------------

This document explains the thinking about the revamped and streamlined
nice-levels implementation in the new Linux scheduler.

这篇文档解释了关于如何在新Linux调度程序实现改进的、流线型的nice优先级的一些想法。

Nice levels were always pretty weak under Linux and people continuously
pestered us to make nice +19 tasks use up much less CPU time.

在Linux下nice优先级都显得相当薄弱，不断有人
缠着我们使用少得多的CPU时间做出高水平的+19任务

 

Unfortunately that was not that easy to implement under the old
scheduler, (otherwise we'd have done it long ago) because nice level
support was historically coupled to timeslice length, and timeslice
units were driven by the HZ tick, so the smallest timeslice was 1/HZ.

不幸的是，在旧调度这不是那么容易实现， （否则我们很久以前早就做了） ，
因为nice优先级的支持是和时间片的长度加在一起的，时间片
单位由HZ滴答声所驱动，所以最小的时间片是1/HZ 。

 

In the O(1) scheduler (in 2003) we changed negative nice levels to be
much stronger than they were before in 2.4 (and people were happy about
that change), and we also intentionally calibrated the linear timeslice
rule so that nice +19 level would be _exactly_ 1 jiffy. To better
understand it, the timeslice graph went like this (cheesy ASCII art
alert!):

在O（1）调度器（在2003年） ，我们改变负的nice优先级使其
远远强于之前在2.4 （人们对这个改变感到很高兴） ，我们也有意校准线性时间片
使得+19级的规则可以被精确的锁定在1这个瞬间。为了更好地了解它
时间片走势如下图所示（ASCII艺术警报）:

 

 

                   A  时间片长度
             \     | [timeslice length]
              \    |
               \   |
                \  |
                 \ |
                  \|___100msecs
                   |^ . _
                   |      ^ . _
                   |            ^ . _
 -*----------------------------------*-----> [nice level]高水平
 -20               |                +19
                   |
                   |

      
So that if someone wanted to really renice tasks, +19 would give a much
bigger hit than the normal linear rule would do. (The solution of
changing the ABI to extend priorities was discarded early on.)

所以，如果有人想真正的优先级任务，将给予+19比普通的线性规律
会做更大的打击。 （改变ABI来扩展它的优先级的这种方案很早就被抛弃了）。

 

This approach worked to some degree for some time, but later on with
HZ=1000 it caused 1 jiffy to be 1 msec, which meant 0.1% CPU usage which
we felt to be a bit excessive. Excessive _not_ because it's too small of
a CPU utilization, but because it causes too frequent (once per
millisec) rescheduling. (and would thus trash the cache, etc. Remember,
this was long ago when hardware was weaker and caches were smaller, and
people were running number crunching apps at nice +19.)

这种方法工作在一定程度上一段时间，但后来与1000HZ 造成1瞬间为1毫秒，
这意味着0.1 ％的CPU使用率我们觉得有点过分。过度并不是因为它CPU的利用率太小，
而是因为它会导致过于频繁（每一次1毫秒）重译。 （因而丢弃了缓存等。记住，
这是很久以前当硬件较弱，缓存较小，人们在+19运行大量数字资料程序，）。

 

 

So for HZ=1000 we changed nice +19 to 5msecs, because that felt like the
right minimal granularity - and this translates to 5% CPU utilization.
But the fundamental HZ-sensitive property for nice+19 still remained,
and we never got a single complaint about nice +19 being too _weak_ in
terms of CPU utilization, we only got complaints about it (still) being
too _strong_ :-)

因此，对于1000HZ ，我们改变了nice+19 为5毫秒的，因为那感觉就像
正确的极小的粒度 - 这意味着5 ％的CPU利用率。
但是nice+19 HZ -敏感的根本属性仍然存在，
我们从来没有得到一个nice+19CPU利用率方面是太弱在的投诉
，我们只得到了关于它仍然很强的的投诉。

 

To sum it up: we always wanted to make nice levels more consistent, but
within the constraints of HZ and jiffies and their nasty design level
coupling to timeslices and granularity it was not really viable.

概括起来讲：我们一直想拍好的更一致的水平，但
由于HZ和滴答声的约束，和他们的设计水平时间片和粒度相连。所以它不是真的可行。

 

The second (less frequent but still periodically occurring) complaint
about Linux's nice level support was its assymetry around the origo
(which you can see demonstrated in the picture above), or more
accurately: the fact that nice level behavior depended on the _absolute_
nice level as well, while the nice API itself is fundamentally
"relative":

第二个（较不频繁，但仍然周期性地发生）投诉
关于Linux的nice优先级支持其周围的组合件
（你可以在上面的图片看到证明），或者更
准确的事实，nice优先级的行为取决于在绝对事物上，
而好的API本身是基本呈相关性 ：

   定义nice）（定义 inc）
   int nice(int inc);

   asmlinkage long sys_nice(int increment)

(the first one is the glibc API, the second one is the syscall API.)
Note that the 'inc' is relative to the current nice level. Tools like
bash's "nice" command mirror this relative API.

（第一个的glibc应用程式介面的，第二个是系统调用的API。 ）
请注意， “增量”是相对于目前的nice优先级。bash之类的工具
的“好”命令镜像此相对的API 。

 

With the old scheduler, if you for example started a niced task with +1
and another task with +2, the CPU split between the two tasks would
depend on the nice level of the parent shell - if it was at nice -10 the
CPU split was different than if it was at +5 or +10.

在旧的调度，如果您对例子开始了NICED的任务+1与
另一个任务+2 ，两个任务之间的CPU分割
依赖于高一级的外壳 - 如果它是在nice-10和
如果它是在+5或+10 的CPU分配是不同的，

 

A third complaint against Linux's nice level support was that negative
nice levels were not 'punchy enough', so lots of people had to resort to
run audio (and other multimedia) apps under RT priorities such as
SCHED_FIFO. But this caused other problems: SCHED_FIFO is not starvation
proof, and a buggy SCHED_FIFO app can also lock up the system for good.

Linux的nice优先级支持的第三个投诉是负
高水平没有足够冲击力'，所以很多人不得不求助于
在RT优先级中（如SCHED_FIFO）运行音频应用程序（以及其他多媒体）
 。但是，这引起了其他问题： SCHED_FIFO是不是资源缺乏
也可以证明，用便携的SCHED_FIFO应用程序锁定系统为好。

 

The new scheduler in v2.6.23 addresses all three types of complaints:

新的调度v2.6.23解决所有三种类型的投诉：

To address the first complaint (of nice levels being not "punchy"
enough), the scheduler was decoupled from 'time slice' and HZ concepts
(and granularity was made a separate concept from nice levels) and thus
it was possible to implement better and more consistent nice +19
support: with the new scheduler nice +19 tasks get a HZ-independent
1.5%, instead of the variable 3%-5%-9% range they got in the old
scheduler.

为了解决第一个投诉（高水平是不是“强而有力”
够了） ，调度从“时间片”和HZ概念两个方面来减低
（从高水平和粒度作为一个单独的概念，），因此
它可以实现更好和更一致的+19支持：在新的调度下，nice+19任务得到一个独立HZ-
1.5 ％，而不是在旧调度下得到的变量3％-5％ -9 ％的范围内，

 

To address the second complaint (of nice levels not being consistent),
the new scheduler makes nice(1) have the same CPU utilization effect on
tasks, regardless of their absolute nice levels. So on the new
scheduler, running a nice +10 and a nice 11 task has the same CPU
utilization "split" between them as running a nice -5 and a nice -4
task. (one will get 55% of the CPU, the other 45%.) That is why nice
levels were changed to be "multiplicative" (or exponential) - that way
it does not matter which nice level you start out from, the 'relative
result' will always be the same.

为了解决第二个投诉，（nice优先级显示不一致），新的调度使得其具有相同的CPU利用率来影响
任务，忽略他们的绝对nice优先级。因此，在新的调度，运行一个nice+10和一个好的11任务具有相同的CPU
使用率分配，它们分别运行了-5和-4的任务。 （人会得到55 ％的CPU ， 45 ％ ）。
这就是为什么nice优先级被改变为“乘法” （或指数） -因为这样无关于你从哪里开始高水平
， “相对结果将始终是相同的。

 

The third complaint (of negative nice levels not being "punchy" enough
and forcing audio apps to run under the more dangerous SCHED_FIFO
scheduling policy) is addressed by the new scheduler almost
automatically: stronger negative nice levels are an automatic
side-effect of the recalibrated dynamic range of nice levels.

第三个投诉（负的nice优先级不具备足够的“冲击力”
并迫使在更危险的SCHED_FIFO的调度策略下运行音频应用程序）
它几乎可以自动由新的调度程序来解决：较强的负高层级是
重新校准高层级动态范围自动产生的副作用。