On Fri, Dec 10, 2021 at 11:11 PM Yeechou Tang <tangyeechou@xxxxxxxxx> wrote: > > Yeechou Tang <tangyeechou@xxxxxxxxx> 于2021年12月10日周五 22:53写道： >> >> yanteng si <siyanteng01@xxxxxxxxx> 于2021年12月10日周五 19:03写道： >>> >>> Tang Yizhou <tangyizhou@xxxxxxxxxx> 于2021年12月10日周五 17:35写道： >>> Subject >>> docs/zh-CN: -> docs/zh_CN: >>> >>> > >>> > Translate scheduler/sched-capacity.rst into Chinese. >>> > >>> > Signed-off-by: Tang Yizhou <tangyizhou@xxxxxxxxxx> >>> > --- >>> > .../zh_CN/scheduler/sched-capacity.rst | 397 ++++++++++++++++++ >>> > 1 file changed, 397 insertions(+) >>> > create mode 100644 Documentation/translations/zh_CN/scheduler/sched-capacity.rst >>> > >>> > diff --git a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst >>> > new file mode 100644 >>> > index 000000000000..9a1633a2a57c >>> > --- /dev/null >>> > +++ b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst >>> > @@ -0,0 +1,397 @@ >>> > +.. SPDX-License-Identifier: GPL-2.0 >>> > +.. include:: ../disclaimer-zh_CN.rst >>> > + >>> > +:Original: Documentation/scheduler/sched-capacity.rst >>> > + >>> > +:翻译: >>> > + >>> > + 唐艺舟 Tang Yizhou <tangyeechou@xxxxxxxxx> >>> > + >>> > +:校译: >>> > + >>> > + 时奎亮 Alex Shi <alexs@xxxxxxxxxx> >>> Signature needs to be aligned. >>> > + >>> > +============= >>> > +算力感知调度 >>> > +============= >>> > + >>> > +1. CPU算力 >>> > +========== >>> > + >>> > +1.1 简介 >>> > +-------- >>> > + >>> > +一般来说，同构的SMP平台由完全相同的CPU构成。异构的平台则由性能特征不同的CPU构成， >>> > +在这样的平台中，CPU不能被认为是相同的。 >>> > + >>> > +我们引入CPU算力（capacity）的概念来测量每个CPU能达到的性能， >>> > +它的值相对系统中性能最强的CPU做过归一化处理。异构系统也被称为非对称CPU算力系统， >>> > +因为它们由不同算力的CPU组成。 >>> > + >>> > +最大可达性能（换言之，最大CPU算力）的差异有两个主要来源: >>> > + >>> > +- 不是所有CPU的微架构都相同。 >>> > +- 在动态电压频率升降（Dynamic Voltage and Frequency Scaling，DVFS）框架中， >>> > + 不是所有的CPU都能达到一样高的操作性能值 >>> > + （Operating Performance Points，OPP。译注，也就是“频率-电压”对）。 >>> > + >>> > +Arm大小核（big.LITTLE）系统是同时具有两种差异的一个例子。相较小核，大核面向性能 >>> > +（拥有更多的流水线层级，更大的缓存，更智能的分支预测器等），通常可以达到更高的操作性能值。 >>> > + >>> > +CPU性能通常由每秒百万指令（Millions of Instructions Per Second，MIPS）表示， >>> > +也可表示为per Hz能执行的指令数，故:: >>> > + >>> > + capacity(cpu) = work_per_hz(cpu) * max_freq(cpu) >>> > + >>> > +1.2 调度器术语 >>> > +-------------- >>> > + >>> > +调度器使用了两种不同的算力值。CPU的 ``capacity_orig`` 是它的最大可达算力， >>> > +即最大可达性能等级。CPU的 ``capacity`` 是 ``capacity_orig`` >>> > +扣除了一些性能损失（比如处理中断的耗时）的值。 >>> > + >>> > +注意CPU的 ``capacity`` 仅仅被设计用于CFS调度类，而 ``capacity_orig`` >>> > +是不感知调度类的。为简洁起见，本文档的剩余部分将不加区分的使用术语 >>> > +``capacity`` 和 ``capacity_orig`` 。 >>> > + >>> > +1.3 平台示例 >>> > +------------ >>> > + >>> > +1.3.1 操作性能值相同 >>> > +~~~~~~~~~~~~~~~~~~~~ >>> > + >>> > +考虑一个假想的双核非对称CPU算力系统，其中 >>> > + >>> > +- work_per_hz(CPU0) = W >>> > +- work_per_hz(CPU1) = W/2 >>> > +- 所有CPU以相同的固定频率运行 >>> > + >>> > +根据上文对算力的定义: >>> > + >>> > +- capacity(CPU0) = C >>> > +- capacity(CPU1) = C/2 >>> > + >>> > +若这是Arm大小核系统，那么CPU0是大核，而CPU1是小核。 >>> > + >>> > +考虑一种周期性产生固定工作量的工作负载，你将会得到类似下图的执行轨迹:: >>> > + >>> > + CPU0 work ^ >>> > + | ____ ____ ____ >>> > + | | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > + CPU1 work ^ >>> > + | _________ _________ ____ >>> > + | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > +CPU0在系统中具有最高算力（C），它使用T个单位时间完成固定工作量W。 >>> > +另一方面，CPU1只有CPU0一半算力，因此在T个单位时间内仅完成工作量W/2。 >>> > + >>> > +1.3.2 最大操作性能值不同 >>> > +~~~~~~~~~~~~~~~~~~~~~~~~ >>> > + >>> > +具有不同算力值的CPU，通常来说最大操作性能值也不同。考虑上一小节提到的CPU >>> > +（也就是说，work_per_hz()相同）: >>> > + >>> > +- max_freq(CPU0) = F >>> > +- max_freq(CPU1) = 2/3 * F >>> > + >>> > +这将推出： >>> > + >>> > +- capacity(CPU0) = C >>> > +- capacity(CPU1) = C/3 >>> > + >>> > +执行1.3.1节描述的工作负载，每个CPU按最大频率运行，结果为:: >>> > + >>> > + CPU0 work ^ >>> > + | ____ ____ ____ >>> > + | | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > + workload on CPU1 >>> > + CPU1 work ^ >>> > + | ______________ ______________ ____ >>> > + | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > +1.4 关于计算方式的注意事项 >>> > +-------------------------- >>> > + >>> > +需要注意的是，使用单一值来表示CPU性能的差异是有些争议的。 >>> > +两个不同的微架构的相对性能差异应该描述为：X%整数运算差异，Y%浮点数运算差异，Z%分支跳转差异， >>> > +等等。尽管如此，使用简单计算方式的结果目前还是令人满意的。 >>> > + >>> > +2. 任务使用率 >>> > +============= >>> > + >>> > +2.1 简介 >>> > +-------- >>> > + >>> > +算力感知调度要求描述任务需求，描述方式要和CPU算力相关。 >>> > +每个调度类可以用不同的方式描述它。任务使用率是CFS独有的描述方式， >>> > +不过在这里介绍它有助于引入更多一般性的概念。 >>> > + >>> > +任务使用率是一种用百分比来描述任务吞吐率需求的方式。一个简单的近似是任务的占空比，也就是说:: >>> > + >>> > + task_util(p) = duty_cycle(p) >>> > + >>> > +在频率固定的SMP系统中，100%的利用率意味着任务是忙等待循环。反之， >>> > +10%的利用率暗示这是一个小周期任务，它在睡眠上花费的时间比执行更多。 >>> > + >>> > +2.2 频率不变性 >>> > +-------------- >>> > + >>> > +一个需要考虑的议题是，工作负载的占空比受CPU正在运行的操作性能值直接影响。 >>> > +考虑以给定的频率F执行周期性工作负载:: >>> > + >>> > + CPU work ^ >>> > + | ____ ____ ____ >>> > + | | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > +可以算出 duty_cycle(p) == 25%。 >>> > + >>> > +现在，考虑以给定频率F/2执行 *同一个* 工作负载:: >>> > + >>> > + CPU work ^ >>> > + | _________ _________ ____ >>> > + | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > +可以算出 duty_cycle(p) == 50%，尽管两次执行中，任务的行为完全一致 >>> > +（也就是说，执行的工作量相同）。 >>> > + >>> > +任务利用率信号可按下面公式处理成频率不变的（译注：这里的术语用到了信号与系统的概念）:: >>> > + >>> > + task_util_freq_inv(p) = duty_cycle(p) * (curr_frequency(cpu) / max_frequency(cpu)) >>> > + >>> > +对上面两个例子运用该公式，可以算出频率不变的任务利用率均为25%。 >>> > + >>> > +2.3 CPU不变性 >>> > +------------- >>> > + >>> > +CPU算力与任务利用率具有类型的效应，在算力不同的CPU上执行完全相同的工作负载， >>> > +将算出不同的占空比。 >>> > + >>> > +考虑1.3.2节提到的系统，也就是说:: >>> > + >>> > +- capacity(CPU0) = C >>> > +- capacity(CPU1) = C/3 >>> > + >>> > +每个CPU按最大频率执行指定周期性工作负载，结果为:: >>> > + >>> > + CPU0 work ^ >>> > + | ____ ____ ____ >>> > + | | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > + CPU1 work ^ >>> > + | ______________ ______________ ____ >>> > + | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + >>> > +也就是说， >>> > + >>> > +- duty_cycle(p) == 25%，如果任务p在CPU0上按最大频率运行。 >>> > +- duty_cycle(p) == 75%，如果任务p在CPU1上按最大频率运行。 >>> > + >>> > +任务利用率信号可按下面公式处理成CPU容量不变的:: >>> > + >>> > + task_util_cpu_inv(p) = duty_cycle(p) * (capacity(cpu) / max_capacity) >>> > + >>> > +其中 ``max_capacity`` 是系统中最高的CPU算力。对上面的例子运用该公式， >>> > +可以算出CPU算力不变的任务利用率均为25%。 >>> > + >>> > +2.4 任务利用率不变量 >>> > +-------------------- >>> > + >>> > +频率和CPU算力不变性都需要被应用到任务利用率的计算中，以便求出真正的不变信号。 >>> > +任务利用率的伪计算公式是同时具备CPU和频率不变性的，也就是说，对于指定任务p:: >>> > + >>> > + curr_frequency(cpu) capacity(cpu) >>> > + task_util_inv(p) = duty_cycle(p) * ------------------- * ------------- >>> > + max_frequency(cpu) max_capacity >>> > + >>> > +也就是说，任务利用率不变量假定任务在系统中最高算力CPU上以最高频率运行，以此描述任务的行为。 >>> > + >>> > +在接下来的章节中提到的任何任务利用率，均是不变量的形式。 >>> > + >>> > +2.5 利用率估算 >>> > +-------------- >>> > + >>> > +由于预测未来的水晶球不存在，当任务第一次变成可运行时，任务的行为和任务利用率均不能被准确预测。 >>> > +CFS调度类基于实体负载跟踪机制（Per-Entity Load Tracking, PELT）维护了少量CPU和任务信号， >>> > +其中之一可以算出平均利用率（与瞬时相反）。 >>> > + >>> > +这意味着，尽管运用“真实的”任务利用率（凭借水晶球）写出算力感知调度的准则， >>> > +但是它的实现将只能用任务利用率的估算值。 >>> > + >>> > +3. 算力感知调度的需求 >>> > +===================== >>> > + >>> > +3.1 CPU算力 >>> > +----------- >>> > + >>> > +当前，Linux无法凭自身算出CPU算力，因此必须要有把这个信息传递给Linux的方式。 >>> > +每个架构必须为此定义arch_scale_cpu_capacity()函数。 >>> > + >>> > +arm和arm64架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中 >>> > +（译注：参考arch_topology.h的percpu变量cpu_scale）， >>> > +它是从capacity-dmips-mhz CPU binding中衍生计算出来的。参见 >>> > +Documentation/devicetree/bindings/arm/cpu-capacity.txt。 >>> > + >>> > +3.2 频率不变性 >>> > +-------------- >>> > + >>> > +如2.2节所述，算力感知调度需要频率不变的任务利用率。 >>> > +每个架构必须为此定义arch_scale_freq_capacity(cpu)函数。 >>> > + >>> > +实现该函数要求计算出每个CPU当前以什么频率在运行。实现它的一种方式是利用硬件计数器 >>> > +（x86的APERF/MPERF，arm64的AMU），它能按CPU当前频率动态可扩展地升降递增计数器的速率。 >>> > +另一种方式是在cpufreq频率变化时直接使用钩子函数，内核此时感知到将要被切换的频率 >>> > +（也被arm/arm64实现了）。 >>> > + >>> > +4. 调度器拓扑结构 >>> > +================= >>> > + >>> > +在构建调度域时，调度器将会发现系统是否表现为非对称CPU算力。如果是，那么： >>> > + >>> > +- sched_asym_cpucapacity静态键（static key）将使能。 >>> > +- SD_ASYM_CPUCAPACITY_FULL标志位将在尽量最低调度域层级中被设置，同时要满足条件： >>> > + 调度域恰好完整包含某个CPU算力值的全部CPU。 >>> > +- SD_ASYM_CPUCAPACITY标志将在所有包含非对称CPU的调度域中被设置。 >>> > + >>> > +sched_asym_cpucapacity静态键的设计意图是，保护为非对称CPU算力系统所准备的代码。 >>> > +不过要注意的是，这个键是系统范围可见的。想象下面使用了cpuset的步骤:: >>> > + >>> > + capacity C/2 C >>> > + ________ ________ >>> > + / \ / \ >>> > + CPUs 0 1 2 3 4 5 6 7 >>> > + \__/ \______________/ >>> > + cpusets cs0 cs1 >>> > + >>> > +可以通过下面的方式创建： >>> > + >>> > +.. code-block:: sh >>> > + >>> > + mkdir /sys/fs/cgroup/cpuset/cs0 >>> > + echo 0-1 > /sys/fs/cgroup/cpuset/cs0/cpuset.cpus >>> > + echo 0 > /sys/fs/cgroup/cpuset/cs0/cpuset.mems >>> > + >>> > + mkdir /sys/fs/cgroup/cpuset/cs1 >>> > + echo 2-7 > /sys/fs/cgroup/cpuset/cs1/cpuset.cpus >>> > + echo 0 > /sys/fs/cgroup/cpuset/cs1/cpuset.mems >>> > + >>> > + echo 0 > /sys/fs/cgroup/cpuset/cpuset.sched_load_balance >>> > + >>> > +由于“这是”非对称CPU算力系统，sched_asym_cpucapacity静态键将使能。 >>> > +然而，CPU 0--1对应的调度域层级，算力值仅有一个，该层级中SD_ASYM_CPUCAPACITY未被设置， >>> > +它描述的是一个SMP区域，也应该被以此处理。 >>> > + >>> > +因此，“典型的”保护非对称CPU算力代码路径的代码模式是： >>> > + >>> > +- 检查sched_asym_cpucapacity静态键 >>> > +- 如果它被使能，接着检查调度域层级中SD_ASYM_CPUCAPACITY标志位是否出现 >>> > + >>> > +5. 算力感知调度的实现 >>> > +===================== >>> > + >>> > +5.1 CFS >>> > +------- >>> > + >>> > +5.1.1 算力适应性（fitness） >>> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > + >>> > +CFS最主要的算力调度准则是:: >>> > + >>> > + task_util(p) < capacity(task_cpu(p)) >>> > + >>> > +它通常被称为算力适应性准则。也就是说，CFS必须保证任务“适合”在某个CPU上运行。 >>> > +如果准则被违反，任务将要更长地消耗该CPU，任务是CPU受限的（CPU-bound）。 >>> > + >>> > +此外，uclamp允许用户空间指定任务的最小和最大利用率，要么以sched_setattr()的方式， >>> > +要么以cgroup接口的方式（参阅Documentation/admin-guide/cgroup-v2.rst）。 >>> > +如其名字所暗示，uclamp可以被用在前一条准则中限制task_util()。 >>> > + >>> > +5.1.2 被唤醒任务的CPU选择 >>> > +~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > + >>> > +CFS任务唤醒的CPU选择，遵循上面描述的算力适应性准则。在此之上， >>> > +uclamp被用来限制任务利用率，这令用户空间对CFS任务的CPU选择有更多的控制。也就是说， >>> > +CFS被唤醒任务的CPU选择，搜索满足以下条件的CPU:: >>> > + >>> > + clamp(task_util(p), task_uclamp_min(p), task_uclamp_max(p)) < capacity(cpu) >>> > + >>> > +通过使用uclamp，举例来说，用户空间可以允许忙等待循环（100%使用率）在任意CPU上运行， >>> > +只要给它设置低的uclamp.max值。相反，uclamp能强制一个小的周期性任务（比如，10%利用率） >>> > +在最高性能的CPU上运行，只要给它设置高的uclamp.min值。 >>> > + >>> > +.. note:: >>> > + >>> > + CFS的被唤醒的任务的CPU选择，可被能耗感知调度（Energy Aware Scheduling，EAS） >>> > + 覆盖，在Documentation/scheduler/sched-energy.rst中描述。 >>> > + >>> > +5.1.3 负载均衡 >>> > +~~~~~~~~~~~~~~ >>> > + >>> > +被唤醒任务的CPU选择的一个病理性的例子是，任务几乎不睡眠，那么也几乎不发生唤醒。考虑:: >>> > + >>> > + w == wakeup event >>> > + >>> > + capacity(CPU0) = C >>> > + capacity(CPU1) = C / 3 >>> > + >>> > + workload on CPU0 >>> > + CPU work ^ >>> > + | _________ _________ ____ >>> > + | | | | | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> time >>> > + w w w >>> > + >>> > + workload on CPU1 >>> > + CPU work ^ >>> > + | ____________________________________________ >>> > + | | >>> > + +----+----+----+----+----+----+----+----+----+----+-> >>> > + w >>> > + >>> > +该工作负载应该在CPU0上运行，不过如果任务满足以下条件之一： >>> > + >>> > +- 一开始发生不合适的调度（不准确的初始利用率估计） >>> > +- 一开始调度正确，但突然需要更多的处理器功率 >>> I think a period can be added because I noticed that the original >>> document seems to have forgotten to add it here, while line 23 was >>> added. >>> >>> Hi Yizhou Alex >>> >>> Yizhou, Honestly, I can appreciate the effort you put into this, but >>> is it really worth breaking a neat block of text just to eliminate a >>> space in the html? After all, the text blocks in English documents are >>> so neat. >>> >>> If this issue is resolved gracefully in the future, it is no longer >>> possible to align the text blocks in the documentation code. This is >>> because doing so would be equivalent to refactoring the documentation, >>> which would destroy the git log, and modifying the currently >>> translated documentation to be unaligned would also face this problem. >>> >>> So, Let's reconsider it carefully? >>> >>> **Sorry. My English is not very well， please allow me to repeat in Chinese:** >>> >>> 艺舟兄，亮兄： >>> >>> 艺舟，说实话，我能体会到你为了解决网页版文档中的空格问题所做的努力，你肯定在翻译时因为换行而绞尽脑汁。但是咱们为了一个空格问题就破坏掉整整齐齐的文本块，这真的值得吗？要知道，英文文档都是很整齐的文本块呀。 >>> >>> 从目前咱们拿到的信息来看，这个空格问题在将来很有可能通过浏览器和渲染引擎解决的，一旦被解决了，已经存在的为了避免空格问题的“非对齐”文档就再也没有改回对齐的可能，因为如果改回对齐就等同于重构整个文档，这将会破坏git >>> log这个宝库。同样，如果我们把现存的已经翻译过的文档改成解决空格问题的“非对齐”状态，依旧会面临破坏git log的问题。 >>> >>> 两位老大哥，这个问题咱们是不是再慎重考虑考虑？ >>> >>> Thanks, >>> Yanteng >> >> >> >> 可以改的，我特意等了一下，没看到Alex在新补丁中加上中文要对齐的规则，以为这是没关系的。 uh, alignment is a default custom in kernel document. I thought it no needs to mention... >> >> 文档无非是个约定，maintainer认为要对齐成方块，我觉得遵从定好的规则就行了。 >> >> Will modify in the next patch. > > > 进一步提问：实际上每一行是不可能完全不提及英文的，比如第一次翻译某个术语，又比如说CPU这种不翻译的。 > 那么在对齐的时候，中英文混排的情况最大列数是多少？假如是50，那么行中有英文时，此行可能很明显偏短， > 依然无法对齐成方块状。 English char will take half width of Chinese char. So when them mix together, we still can count the width/column to less than 100 English char width in a line. On this point, 'vi' do a good job, it show correct width for both. Guess other editor could do this work too, you may just need figure out some configuration? Thanks Alex > >> >> >> Thanks, >> Tang >> >>
