[PATCH v3 6/7] docs/zh_CN: Translate timers/no_hz.rst

Patch content 2 changed files

Translate .../timers/no_hz.rst into Chinese.Update timers/index.rst to include the translated file. Update translation through commit 5097cbcb38e6("sched/isolation: Prevent boot crash when the boot CPU is nohz_full") Signed-off-by: Xingqiu Xu <hilbertanjou83@gmail.com>--- .../translations/zh_CN/timers/index.rst       |   2 +- .../translations/zh_CN/timers/no_hz.rst       | 337 ++++++++++++++++++ 2 files changed, 338 insertions(+), 1 deletion(-) create mode 100644 Documentation/translations/zh_CN/timers/no_hz.rst diff --git a/Documentation/translations/zh_CN/timers/index.rst b/Documentation/translations/zh_CN/timers/index.rstindex 485e6a95c600..17f35d87645a 100644--- a/Documentation/translations/zh_CN/timers/index.rst+++ b/Documentation/translations/zh_CN/timers/index.rst@@ -18,11 +18,11 @@     highres     hpet     hrtimers+    no_hz     timekeeping  TODOList: -* no_hz * delay_sleep_functions  .. only::  subproject and htmldiff --git a/Documentation/translations/zh_CN/timers/no_hz.rst b/Documentation/translations/zh_CN/timers/no_hz.rstnew file mode 100644index 000000000000..b1d43169ece0--- /dev/null+++ b/Documentation/translations/zh_CN/timers/no_hz.rst@@ -0,0 +1,337 @@+.. SPDX-License-Identifier: GPL-2.0++.. include:: ../disclaimer-zh_CN.rst++:Original: Documentation/timers/no_hz.rst++:翻译:++  徐兴球 Xingqiu Xu <hilbertanjou83@gmail.com>++============================+NO_HZ：减少调度时钟刻度+============================+++本文档描述了可以减少调度时钟中断数量的+Kconfig 选项和引导参数，从而提高能效并减+少操作系统抖动。减少操作系统抖动对于某些类+型的计算密集型高性能计算（HPC）应用程序以+及实时应用程序非常重要。++管理调度时钟中断（也称为"调度时钟刻度"或简+称"刻度"）有三种主要方式：++1.	从不省略调度时钟刻度（CONFIG_HZ_PERIODIC=y+	或对于旧内核为 CONFIG_NO_HZ=n）。您通常+	不会想要选择此选项。++2.	在空闲 CPU 上省略调度时钟刻度+	（CONFIG_NO_HZ_IDLE=y 或对于旧内核为+	CONFIG_NO_HZ=y）。这是最常见的方法，应+	该是默认值。++3.	在空闲或只有一个可运行任务的 CPU 上省+	略调度时钟刻度（CONFIG_NO_HZ_FULL=y）。+	除非您正在运行实时应用程序或某些类型的+	HPC 工作负载，否则您通常不会想要此选项。++这三种情况将在以下三节中描述，然后是关于+RCU 特定考虑的第三节，讨论测试的第四节，以+及列出已知问题的第五节和最后一节。+++从不省略调度时钟刻度+====================++来自 1990 年代和 21 世纪初期的非常旧版本+的 Linux 无法省略调度时钟刻度。事实证明，+在某些情况下，这种老派方法仍然是正确的方法，+例如，在具有大量使用短暂 CPU 突发的任务的+繁重工作负载中，其中有非常频繁的空闲期，但+这些空闲期也非常短（数十或数百微秒）。对于+这些类型的工作负载，调度时钟中断通常无论如+何都会传递，因为每个 CPU 经常会有多个可运+行的任务。在这些情况下，尝试关闭调度时钟中+断除了增加进出空闲以及在用户和内核执行之间+转换的开销外没有任何效果。++可以使用 CONFIG_HZ_PERIODIC=y（或对于旧内+核为 CONFIG_NO_HZ=n）选择此操作模式。++但是，如果您正在运行具有较长空闲期的轻量级+工作负载，则无法省略调度时钟中断将导致过度+的功耗。这在电池供电的设备上尤其糟糕，它会+导致电池寿命极短。如果您正在运行轻量级工作+负载，因此应该阅读以下部分。++此外，如果您正在运行实时工作负载或具有短迭+代的 HPC 工作负载，调度时钟中断可能会降低+您的应用程序性能。如果这描述了您的工作负载，+您应该阅读以下两节。+++为空闲 CPU 省略调度时钟刻度+===========================++如果 CPU 处于空闲状态，向其发送调度时钟中+断意义不大。毕竟，调度时钟中断的主要目的是+强制繁忙的 CPU 在多个任务之间转移其注意力，+而空闲 CPU 没有需要转移注意力的任务。++不接收调度时钟中断的空闲 CPU 被称为+"dyntick-idle"、"处于 dyntick-idle 模式"、+"处于 nohz 模式"或"无刻度运行"。本文档的其+余部分将使用"dyntick-idle 模式"。++CONFIG_NO_HZ_IDLE=y Kconfig 选项使内核避+免向空闲 CPU 发送调度时钟中断，这对于电池+供电的设备和高度虚拟化的大型机都至关重要。+运行 CONFIG_HZ_PERIODIC=y 内核的电池供电设+备将非常快速地耗尽其电池，轻松地比运行+CONFIG_NO_HZ_IDLE=y 内核的同一设备快 2-3+倍。运行 1,500 个操作系统实例的大型机可能+会发现其一半的 CPU 时间被不必要的调度时钟+中断消耗。在这些情况下，有强烈的动机避免向+空闲 CPU 发送调度时钟中断。也就是说，+dyntick-idle 模式不是免费的：++1.	它增加了进出空闲循环的路径上执行的指令+	数量。++2.	在许多架构上，dyntick-idle 模式还会增+	加昂贵的时钟重新编程操作的数量。++因此，具有激进实时响应约束的系统通常运行+CONFIG_HZ_PERIODIC=y 内核（或对于旧内核为+CONFIG_NO_HZ=n），以避免降低从空闲转换延迟。++还有一个引导参数"nohz="，可用于通过指定+"nohz=off"在 CONFIG_NO_HZ_IDLE=y 内核中禁+用 dyntick-idle 模式。默认情况下，+CONFIG_NO_HZ_IDLE=y 内核使用"nohz=on"引导，+启用 dyntick-idle 模式。+++为只有一个可运行任务的 CPU 省略调度时钟刻度+=============================================++如果 CPU 只有一个可运行任务，向其发送调度+时钟中断意义不大，因为没有其他任务可以切换+到。请注意，为只有一个可运行任务的 CPU 省+略调度时钟刻度也意味着为空闲 CPU 省略它们。++CONFIG_NO_HZ_FULL=y Kconfig 选项使内核避+免向具有单个可运行任务的 CPU 发送调度时钟+中断，此类 CPU 被称为"自适应刻度 CPU"。这+对于具有激进实时响应约束的应用程序非常重要，+因为它允许它们通过调度时钟中断的最大持续时+间来改善其最坏情况响应时间。对于计算密集型+短迭代工作负载也很重要：如果在给定迭代期间+任何 CPU 被延迟，所有其他 CPU 将被迫在延迟+的 CPU 完成时空闲等待。因此，延迟乘以比+CPU 数量少一的数量。在这些情况下，再次有强+烈的动机避免发送调度时钟中断。++默认情况下，没有 CPU 将是自适应刻度 CPU。+"nohz_full=" 引导参数指定自适应刻度 CPU。+例如，"nohz_full=1,6-8" 表示 CPU 1、6、7+和 8 是自适应刻度 CPU。请注意，您被禁止将+所有 CPU 标记为自适应刻度 CPU：至少必须保+留一个非自适应刻度 CPU 在线以处理时间保持+任务，以确保在自适应刻度 CPU 上像+gettimeofday() 这样的系统调用返回准确的值。+（这对于 CONFIG_NO_HZ_IDLE=y 不是问题，因+为没有运行中的用户进程来观察时钟速率的轻微+漂移。）请注意，这意味着您的系统必须至少有+两个 CPU，CONFIG_NO_HZ_FULL=y 才能为您做+任何事情。++最后，自适应刻度 CPU 必须卸载其 RCU 回调。+这在下面的"RCU 影响"部分中介绍。++通常，CPU 尽可能长时间保持在自适应刻度模+式下。特别是，转换到内核模式不会自动更改模+式。相反，CPU 只有在需要时才会退出自适应刻+度模式，例如，如果该 CPU 将 RCU 回调排入+队列。++就像 dyntick-idle 模式一样，自适应刻度模+式的好处不是免费的：++1.	CONFIG_NO_HZ_FULL 选择 CONFIG_NO_HZ_COMMON，+	因此您不能在没有 dyntick idle 的情况下+	运行自适应刻度。这种依赖关系延伸到实现+	中，因此 CONFIG_NO_HZ_IDLE 的所有成本+	也由 CONFIG_NO_HZ_FULL 承担。++2.	由于需要通知内核子系统（例如 RCU）有关+	模式更改，用户/内核转换稍微昂贵一些。++3.	POSIX CPU 定时器阻止 CPU 进入自适应刻+	度模式。需要基于 CPU 时间消耗采取行动+	的实时应用程序需要使用其他方法来实现。++4.	如果待处理的 perf 事件多于硬件可以容纳+	的，它们通常会轮转，以便随着时间的推移+	收集所有事件。自适应刻度模式可能会阻止+	这种轮转发生。这可能会通过阻止具有大量+	待处理 perf 事件的 CPU 进入自适应刻度+	模式来修复。++5.	自适应刻度 CPU 的调度程序统计信息可能+	与非自适应刻度 CPU 的统计信息计算方式+	略有不同。这可能反过来扰乱实时任务的负+	载平衡。++尽管预计随着时间的推移会有所改进，但自适应+刻度对于许多类型的实时和计算密集型应用程序+非常有用。但是，上面列出的缺点意味着自适应+刻度不应该（还）默认启用。+++RCU 影响+========++在某些情况下，不能允许空闲 CPU 进入+dyntick-idle 模式或自适应刻度模式，最常见+的是当该 CPU 有 RCU 回调挂起时。++通过使用 CONFIG_RCU_NOCB_CPU=y Kconfig 选+项将 RCU 回调处理卸载到"rcuo"内核线程来避+免这种情况。可以使用"rcu_nocbs=" 内核引导+参数选择要卸载的特定 CPU，该参数接受逗号分+隔的 CPU 和 CPU 范围列表，例如，"1,3-5"选+择 CPU 1、3、4 和 5。请注意，由"nohz_full"+内核引导参数指定的 CPU 也会被卸载。++卸载的 CPU 将永远不会排队 RCU 回调，因此+RCU 永远不会阻止卸载的 CPU 进入+dyntick-idle 模式或自适应刻度模式。也就是+说，请注意，如果需要，将"rcuo"内核线程固定+到特定 CPU 取决于用户空间。否则，调度程序+将决定在哪里运行它们，这可能是也可能不是您+希望它们运行的地方。+++测试+====++因此，您启用了本文档中描述的所有操作系统抖+动功能，但在工作负载的行为中看不到任何变化。+这是因为您的工作负载受操作系统抖动的影响不+大，还是因为其他东西挡在了路上？本节通过提+供一个简单的操作系统抖动测试套件来帮助回答+这个问题，该套件可在以下 git 存档的 master+分支上获得：++git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git++克隆此存档并按照 README 文件中的说明进行+操作。此测试过程将产生一个跟踪，允许您评估+是否成功从系统中删除了操作系统抖动。如果此+跟踪显示您已尽可能多地删除了操作系统抖动，+那么您可以得出结论，您的工作负载对操作系统+抖动不是那么敏感。++注意：此测试要求您的系统至少有两个 CPU。我+们目前没有从单 CPU 系统中删除操作系统抖动+的好方法。+++已知问题+========++*	Dyntick-idle 会稍微减慢进出空闲的转换。+	在实践中，除了最激进的实时工作负载外，+	这不是问题，它们可以选择禁用+	dyntick-idle 模式，大多数工作负载都采+	用了这个选项。但是，一些工作负载无疑会+	希望使用自适应刻度来消除调度时钟中断延+	迟。以下是这些工作负载的一些选项：++	a.	使用用户空间的 PMQOS 通知内核您的+		延迟要求（首选）。++	b.	在 x86 系统上，使用"idle=mwait"引导+		参数。++	c.	在 x86 系统上，使用"intel_idle.max_cstate="+		来限制最大 C 状态深度。++	d.	在 x86 系统上，使用"idle=poll"引导+		参数。但是，请注意，使用此参数可能+		会导致 CPU 过热，这可能会导致热节+		流降低您的延迟——而且这种降低可能比+		dyntick-idle 更糟糕。此外，此参数+		有效地禁用了 Intel CPU 上的 Turbo+		Mode，这会显著降低最大性能。++*	自适应刻度会稍微减慢用户/内核转换。对于+	计算密集型工作负载，这不会成为问题，因+	为它们很少有此类转换。需要仔细的基准测+	试来确定其他工作负载是否受到此效果的显+	著影响。++*	除非给定 CPU 只有一个可运行任务，否则自+	适应刻度不会执行任何操作，即使还有许多+	其他情况不需要调度时钟刻度。举一个例子，+	考虑一个 CPU，它有一个可运行的高优先级+	SCHED_FIFO 任务和任意数量的低优先级+	SCHED_OTHER 任务。在这种情况下，需要+	CPU 运行 SCHED_FIFO 任务，直到它阻塞或+	某个其他更高优先级的任务在此 CPU 上唤醒+	（或被分配给此 CPU），因此向此 CPU 发+	送调度时钟中断是没有意义的。但是，当前+	实现仍然向具有单个可运行 SCHED_FIFO 任+	务和多个可运行 SCHED_OTHER 任务的 CPU+	发送调度时钟中断，即使这些中断是不必要的。++	即使在给定 CPU 上有多个可运行任务时，在+	当前运行任务的时间片到期之前中断该 CPU+	也意义不大，这几乎总是比下一个调度时钟+	中断的时间长得多。++	更好地处理这些情况是未来的工作。++*	需要重新启动才能重新配置自适应空闲和+	RCU 回调卸载。如果需要，可以提供运行时+	重新配置，但是，由于在运行时重新配置+	RCU 的复杂性，需要有一个非常好的理由。+	特别是考虑到您有简单的选项，即从所有+	CPU 卸载 RCU 回调，并在您想要固定它们时+	将它们固定到您想要的位置。++*	需要额外的配置来处理操作系统抖动的其他+	来源，包括中断和系统实用程序任务和进程。+	此配置通常涉及将中断和任务绑定到特定+	CPU。++*	某些操作系统抖动源目前只能通过约束工作+	负载来消除。例如，消除由于全局 TLB+	shootdown 引起的操作系统抖动的唯一方法+	是避免导致这些 shootdown 的取消映射操+	作（例如内核模块卸载操作）。再举一个例+	子，通过使用巨页并通过约束应用程序使用+	的内存量，可以减少（在某些情况下消除）+	页面错误和 TLB 未命中。预先发生工作集+	也可能有帮助，尤其是与 mlock() 和+	mlockall() 系统调用结合使用时。++*	除非所有 CPU 都处于空闲状态，否则至少一+	个 CPU 必须保持调度时钟中断运行以支持准+	确的时间保持。++*	如果可能有一些自适应刻度 CPU，即使所有+	CPU 都处于空闲状态，也将至少有一个 CPU+	保持调度时钟中断运行。++	更好地处理这种情况是正在进行的工作。++*	某些进程处理操作仍然需要偶尔的调度时钟+	刻度。这些操作包括计算 CPU 负载、维护+	sched average、计算 CFS 实体 vruntime、+	计算 avenrun 以及执行负载平衡。它们当前+	通过每秒左右的调度时钟刻度来容纳。正在+	进行的工作将消除对这些不频繁的调度时钟+	刻度的需求。-- 2.34.1