diff options
| -rw-r--r-- | Documentation/timers/NO_HZ.txt | 58 |
1 files changed, 49 insertions, 9 deletions
diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt index 5b5322024067..d5323e075550 100644 --- a/Documentation/timers/NO_HZ.txt +++ b/Documentation/timers/NO_HZ.txt | |||
| @@ -7,21 +7,59 @@ efficiency and reducing OS jitter. Reducing OS jitter is important for | |||
| 7 | some types of computationally intensive high-performance computing (HPC) | 7 | some types of computationally intensive high-performance computing (HPC) |
| 8 | applications and for real-time applications. | 8 | applications and for real-time applications. |
| 9 | 9 | ||
| 10 | There are two main contexts in which the number of scheduling-clock | 10 | There are three main ways of managing scheduling-clock interrupts |
| 11 | interrupts can be reduced compared to the old-school approach of sending | 11 | (also known as "scheduling-clock ticks" or simply "ticks"): |
| 12 | a scheduling-clock interrupt to all CPUs every jiffy whether they need | ||
| 13 | it or not (CONFIG_HZ_PERIODIC=y or CONFIG_NO_HZ=n for older kernels): | ||
| 14 | 12 | ||
| 15 | 1. Idle CPUs (CONFIG_NO_HZ_IDLE=y or CONFIG_NO_HZ=y for older kernels). | 13 | 1. Never omit scheduling-clock ticks (CONFIG_HZ_PERIODIC=y or |
| 14 | CONFIG_NO_HZ=n for older kernels). You normally will -not- | ||
| 15 | want to choose this option. | ||
| 16 | 16 | ||
| 17 | 2. CPUs having only one runnable task (CONFIG_NO_HZ_FULL=y). | 17 | 2. Omit scheduling-clock ticks on idle CPUs (CONFIG_NO_HZ_IDLE=y or |
| 18 | CONFIG_NO_HZ=y for older kernels). This is the most common | ||
| 19 | approach, and should be the default. | ||
| 18 | 20 | ||
| 19 | These two cases are described in the following two sections, followed | 21 | 3. Omit scheduling-clock ticks on CPUs that are either idle or that |
| 22 | have only one runnable task (CONFIG_NO_HZ_FULL=y). Unless you | ||
| 23 | are running realtime applications or certain types of HPC | ||
| 24 | workloads, you will normally -not- want this option. | ||
| 25 | |||
| 26 | These three cases are described in the following three sections, followed | ||
| 20 | by a third section on RCU-specific considerations and a fourth and final | 27 | by a third section on RCU-specific considerations and a fourth and final |
| 21 | section listing known issues. | 28 | section listing known issues. |
| 22 | 29 | ||
| 23 | 30 | ||
| 24 | IDLE CPUs | 31 | NEVER OMIT SCHEDULING-CLOCK TICKS |
| 32 | |||
| 33 | Very old versions of Linux from the 1990s and the very early 2000s | ||
| 34 | are incapable of omitting scheduling-clock ticks. It turns out that | ||
| 35 | there are some situations where this old-school approach is still the | ||
| 36 | right approach, for example, in heavy workloads with lots of tasks | ||
| 37 | that use short bursts of CPU, where there are very frequent idle | ||
| 38 | periods, but where these idle periods are also quite short (tens or | ||
| 39 | hundreds of microseconds). For these types of workloads, scheduling | ||
| 40 | clock interrupts will normally be delivered any way because there | ||
| 41 | will frequently be multiple runnable tasks per CPU. In these cases, | ||
| 42 | attempting to turn off the scheduling clock interrupt will have no effect | ||
| 43 | other than increasing the overhead of switching to and from idle and | ||
| 44 | transitioning between user and kernel execution. | ||
| 45 | |||
| 46 | This mode of operation can be selected using CONFIG_HZ_PERIODIC=y (or | ||
| 47 | CONFIG_NO_HZ=n for older kernels). | ||
| 48 | |||
| 49 | However, if you are instead running a light workload with long idle | ||
| 50 | periods, failing to omit scheduling-clock interrupts will result in | ||
| 51 | excessive power consumption. This is especially bad on battery-powered | ||
| 52 | devices, where it results in extremely short battery lifetimes. If you | ||
| 53 | are running light workloads, you should therefore read the following | ||
| 54 | section. | ||
| 55 | |||
| 56 | In addition, if you are running either a real-time workload or an HPC | ||
| 57 | workload with short iterations, the scheduling-clock interrupts can | ||
| 58 | degrade your applications performance. If this describes your workload, | ||
| 59 | you should read the following two sections. | ||
| 60 | |||
| 61 | |||
| 62 | OMIT SCHEDULING-CLOCK TICKS FOR IDLE CPUs | ||
| 25 | 63 | ||
| 26 | If a CPU is idle, there is little point in sending it a scheduling-clock | 64 | If a CPU is idle, there is little point in sending it a scheduling-clock |
| 27 | interrupt. After all, the primary purpose of a scheduling-clock interrupt | 65 | interrupt. After all, the primary purpose of a scheduling-clock interrupt |
| @@ -59,10 +97,12 @@ By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling | |||
| 59 | dyntick-idle mode. | 97 | dyntick-idle mode. |
| 60 | 98 | ||
| 61 | 99 | ||
| 62 | CPUs WITH ONLY ONE RUNNABLE TASK | 100 | OMIT SCHEDULING-CLOCK TICKS FOR CPUs WITH ONLY ONE RUNNABLE TASK |
| 63 | 101 | ||
| 64 | If a CPU has only one runnable task, there is little point in sending it | 102 | If a CPU has only one runnable task, there is little point in sending it |
| 65 | a scheduling-clock interrupt because there is no other task to switch to. | 103 | a scheduling-clock interrupt because there is no other task to switch to. |
| 104 | Note that omitting scheduling-clock ticks for CPUs with only one runnable | ||
| 105 | task implies also omitting them for idle CPUs. | ||
| 66 | 106 | ||
| 67 | The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid | 107 | The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid |
| 68 | sending scheduling-clock interrupts to CPUs with a single runnable task, | 108 | sending scheduling-clock interrupts to CPUs with a single runnable task, |