Lines Matching refs:nice

4 :Original: Documentation/scheduler/sched-nice-design.rst
11 调度器nice值设计
14 本文档解释了新的Linux调度器中修改和精简后的nice级别的实现思路。
16 Linux的nice级别总是非常脆弱，人们持续不断地缠着我们，让nice +19的任务占用
20 nice级别的支持在历史上是与时间片长度耦合的，而时间片单位是由HZ滴答驱动的，
23 在O(1)调度器中（2003年），我们改变了负的nice级别，使它们比2.4内核更强
24 （人们对这一变化很满意），而且我们还故意校正了线性时间片准则，使得nice +19
39  -*----------------------------------*-----> [nice level]
51 nice +19级别运行数量颇多的应用程序）。
53 因此，对于HZ=1000，我们将nice +19改为5毫秒，因为这感觉像是正确的最小
54 粒度——这相当于5%的CPU利用率。但nice +19的根本的HZ敏感属性依然保持不变，
55 我们没有收到过关于nice +19在CPU利用率方面太 _弱_ 的任何抱怨，我们只收到
58 总结一下：我们一直想让nice各级别一致性更强，但在HZ和jiffies的限制下，以及
59 nice级别与时间片、调度粒度耦合是令人讨厌的设计，这一目标并不真正可行。
61 第二个关于Linux nice级别支持的抱怨是（不那么频繁，但仍然定期发生），它
63 nice级别的行为取决于 _绝对的_ nice级别，而nice应用程序接口本身从根本上
66    int nice(int inc);
71 注意，“inc”是相对当前nice级别而言的，类似bash的“nice”命令等工具是这个
74 在旧的调度器中，举例来说，如果你以nice +1启动一个任务，并以nice +2启动
75 另一个任务，这两个任务的CPU分配将取决于父外壳程序的nice级别——如果它是
76 nice -10，那么CPU的分配不同于+5或+10。
78 第三个关于Linux nice级别支持的抱怨是，负数nice级别“不够有力”，以很多人
85 为了解决第一个抱怨（nice级别不够“有力”），调度器与“时间片”、HZ的概念
86 解耦（调度粒度被处理成一个和nice级别独立的概念），因此有可能实现更好、
87 更一致的nice +19支持：在新的调度器中，nice +19的任务得到一个HZ无关的
90 为了解决第二个抱怨（nice各级别不一致），新调度器令调用nice(1)对各任务的
91 CPU利用率有相同的影响，无论其绝对nice级别如何。所以在新调度器上，运行一个
92 nice +10和一个nice +11的任务会与运行一个nice -5和一个nice -4的任务的
94 nice级别被改为“乘法”（或指数）——这样的话，不管你从哪个级别开始，“相对”
97 第三个抱怨（负数nice级别不够“有力”，并迫使音频应用程序在更危险的
99 具有重新校正nice级别动态范围的自动化副作用。