요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
장치와 IRQ thread
kernel-per-CPU-kthreads.rst:34-79eHCA, threaded IRQ와 Bluetooth per-CPU kthread의 jitter 완화 방법을 설명합니다.
softirq vector
kernel-per-CPU-kthreads.rst:80-220timer, network, block, tasklet, scheduler, hrtimer와 RCU softirq를 각각 격리합니다.
workqueue와 RCU worker
kernel-per-CPU-kthreads.rst:221-325kworker와 RCU callback thread의 affinity, build option과 runtime 제어를 안내합니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
==========================================
Reducing OS jitter due to per-cpu kthreads
==========================================
This document lists per-CPU kthreads in the Linux kernel and presents
options to control their OS jitter. Note that non-per-CPU kthreads are
not listed here. To reduce OS jitter from non-per-CPU kthreads, bind
them to a "housekeeping" CPU dedicated to such work.
References
==========
- Documentation/core-api/irq/irq-affinity.rst: Binding interrupts to sets of CPUs.
- Documentation/admin-guide/cgroup-v1: Using cgroups to bind tasks to sets of CPUs.
- man taskset: Using the taskset command to bind tasks to sets
of CPUs.
- man sched_setaffinity: Using the sched_setaffinity() system
call to bind tasks to sets of CPUs.
- /sys/devices/system/cpu/cpuN/online: Control CPU N's hotplug state,
writing "0" to offline and "1" to online.
- In order to locate kernel-generated OS jitter on CPU N:
cd /sys/kernel/tracing
echo 1 > max_graph_depth # Increase the "1" for more detail
echo function_graph > current_tracer
# run workload
cat per_cpu/cpuN/trace
kthreads
========
Name:
ehca_comp/%u
Purpose:
Periodically process Infiniband-related work.
To reduce its OS jitter, do any of the following:
1. Don't use eHCA Infiniband hardware, instead choosing hardware
that does not require per-CPU kthreads. This will prevent these
kthreads from being created in the first place. (This will
work for most people, as this hardware, though important, is
relatively old and is produced in relatively low unit volumes.)
2. Do all eHCA-Infiniband-related work on other CPUs, including
interrupts.
3. Rework the eHCA driver so that its per-CPU kthreads are
provisioned only on selected CPUs.
Name:
irq/%d-%s
Purpose:
Handle threaded interrupts.
To reduce its OS jitter, do the following:
1. Use irq affinity to force the irq threads to execute on
some other CPU.
Name:
kcmtpd_ctr_%d
Purpose:
Handle Bluetooth work.
To reduce its OS jitter, do one of the following:
1. Don't use Bluetooth, in which case these kthreads won't be
created in the first place.
2. Use irq affinity to force Bluetooth-related interrupts to
occur on some other CPU and furthermore initiate all
Bluetooth activity on some other CPU.
Name:
ksoftirqd/%u
Purpose:
Execute softirq handlers when threaded or when under heavy load.
To reduce its OS jitter, each softirq vector must be handled
separately as follows:
TIMER_SOFTIRQ
-------------
Do all of the following:
1. To the extent possible, keep the CPU out of the kernel when it
is non-idle, for example, by avoiding system calls and by forcing
both kernel threads and interrupts to execute elsewhere.
2. Build with CONFIG_HOTPLUG_CPU=y. After boot completes, force
the CPU offline, then bring it back online. This forces
recurring timers to migrate elsewhere. If you are concerned
with multiple CPUs, force them all offline before bringing the
first one back online. Once you have onlined the CPUs in question,
do not offline any other CPUs, because doing so could force the
timer back onto one of the CPUs in question.
NET_TX_SOFTIRQ and NET_RX_SOFTIRQ
---------------------------------
Do all of the following:
1. Force networking interrupts onto other CPUs.
2. Initiate any network I/O on other CPUs.
3. Once your application has started, prevent CPU-hotplug operations
from being initiated from tasks that might run on the CPU to
be de-jittered. (It is OK to force this CPU offline and then
bring it back online before you start your application.)
BLOCK_SOFTIRQ
-------------
Do all of the following:
1. Force block-device interrupts onto some other CPU.
2. Initiate any block I/O on other CPUs.
3. Once your application has started, prevent CPU-hotplug operations
from being initiated from tasks that might run on the CPU to
be de-jittered. (It is OK to force this CPU offline and then
bring it back online before you start your application.)
IRQ_POLL_SOFTIRQ
----------------
Do all of the following:
1. Force block-device interrupts onto some other CPU.
2. Initiate any block I/O and block-I/O polling on other CPUs.
3. Once your application has started, prevent CPU-hotplug operations
from being initiated from tasks that might run on the CPU to
be de-jittered. (It is OK to force this CPU offline and then
bring it back online before you start your application.)
TASKLET_SOFTIRQ
---------------
Do one or more of the following:
1. Avoid use of drivers that use tasklets. (Such drivers will contain
calls to things like tasklet_schedule().)
2. Convert all drivers that you must use from tasklets to workqueues.
3. Force interrupts for drivers using tasklets onto other CPUs,
and also do I/O involving these drivers on other CPUs.
SCHED_SOFTIRQ
-------------
Do all of the following:
1. Avoid sending scheduler IPIs to the CPU to be de-jittered,
for example, ensure that at most one runnable kthread is present
on that CPU. If a thread that expects to run on the de-jittered
CPU awakens, the scheduler will send an IPI that can result in
a subsequent SCHED_SOFTIRQ.
2. CONFIG_NO_HZ_FULL=y and ensure that the CPU to be de-jittered
is marked as an adaptive-ticks CPU using the "nohz_full="
boot parameter. This reduces the number of scheduler-clock
interrupts that the de-jittered CPU receives, minimizing its
chances of being selected to do the load balancing work that
runs in SCHED_SOFTIRQ context.
3. To the extent possible, keep the CPU out of the kernel when it
is non-idle, for example, by avoiding system calls and by
forcing both kernel threads and interrupts to execute elsewhere.
This further reduces the number of scheduler-clock interrupts
received by the de-jittered CPU.
HRTIMER_SOFTIRQ
---------------
Do all of the following:
1. To the extent possible, keep the CPU out of the kernel when it
is non-idle. For example, avoid system calls and force both
kernel threads and interrupts to execute elsewhere.
2. Build with CONFIG_HOTPLUG_CPU=y. Once boot completes, force the
CPU offline, then bring it back online. This forces recurring
timers to migrate elsewhere. If you are concerned with multiple
CPUs, force them all offline before bringing the first one
back online. Once you have onlined the CPUs in question, do not
offline any other CPUs, because doing so could force the timer
back onto one of the CPUs in question.
RCU_SOFTIRQ
-----------
Do at least one of the following:
1. Offload callbacks and keep the CPU in either dyntick-idle or
adaptive-ticks state by doing all of the following:
a. CONFIG_NO_HZ_FULL=y and ensure that the CPU to be
de-jittered is marked as an adaptive-ticks CPU using the
"nohz_full=" boot parameter. Bind the rcuo kthreads to
housekeeping CPUs, which can tolerate OS jitter.
b. To the extent possible, keep the CPU out of the kernel
when it is non-idle, for example, by avoiding system
calls and by forcing both kernel threads and interrupts
to execute elsewhere.
2. Enable RCU to do its processing remotely via dyntick-idle by
doing all of the following:
a. Build with CONFIG_NO_HZ=y.
b. Ensure that the CPU goes idle frequently, allowing other
CPUs to detect that it has passed through an RCU quiescent
state. If the kernel is built with CONFIG_NO_HZ_FULL=y,
userspace execution also allows other CPUs to detect that
the CPU in question has passed through a quiescent state.
c. To the extent possible, keep the CPU out of the kernel
when it is non-idle, for example, by avoiding system
calls and by forcing both kernel threads and interrupts
to execute elsewhere.
Name:
kworker/%u:%d%s (cpu, id, priority)
Purpose:
Execute workqueue requests
To reduce its OS jitter, do any of the following:
1. Run your workload at a real-time priority, which will allow
preempting the kworker daemons.
2. A given workqueue can be made visible in the sysfs filesystem
by passing the WQ_SYSFS to that workqueue's alloc_workqueue().
Such a workqueue can be confined to a given subset of the
CPUs using the ``/sys/devices/virtual/workqueue/*/cpumask`` sysfs
files. The set of WQ_SYSFS workqueues can be displayed using
"ls /sys/devices/virtual/workqueue". That said, the workqueues
maintainer would like to caution people against indiscriminately
sprinkling WQ_SYSFS across all the workqueues. The reason for
caution is that it is easy to add WQ_SYSFS, but because sysfs is
part of the formal user/kernel API, it can be nearly impossible
to remove it, even if its addition was a mistake.
3. Do any of the following needed to avoid jitter that your
application cannot tolerate:
a. Avoid using oprofile, thus avoiding OS jitter from
wq_sync_buffer().
b. Limit your CPU frequency so that a CPU-frequency
governor is not required, possibly enlisting the aid of
special heatsinks or other cooling technologies. If done
correctly, and if you CPU architecture permits, you should
be able to build your kernel with CONFIG_CPU_FREQ=n to
avoid the CPU-frequency governor periodically running
on each CPU, including cs_dbs_timer() and od_dbs_timer().
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
c. As of v3.18, Christoph Lameter's on-demand vmstat workers
commit prevents OS jitter due to vmstat_update() on
CONFIG_SMP=y systems. Before v3.18, is not possible
to entirely get rid of the OS jitter, but you can
decrease its frequency by writing a large value to
/proc/sys/vm/stat_interval. The default value is HZ,
for an interval of one second. Of course, larger values
will make your virtual-memory statistics update more
slowly. Of course, you can also run your workload at
a real-time priority, thus preempting vmstat_update(),
but if your workload is CPU-bound, this is a bad idea.
However, there is an RFC patch from Christoph Lameter
(based on an earlier one from Gilad Ben-Yossef) that
reduces or even eliminates vmstat overhead for some
workloads at https://lore.kernel.org/r/00000140e9dfd6bd-40db3d4f-c1be-434f-8132-7820f81bb586-000000@email.amazonses.com.
d. If running on high-end powerpc servers, build with
CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS
daemon from running on each CPU every second or so.
(This will require editing Kconfig files and will defeat
this platform's RAS functionality.) This avoids jitter
due to the rtas_event_scan() function.
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
e. If running on PowerMAC, build your kernel with
CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
avoiding OS jitter from rackmeter_do_timer().
Name:
rcuc/%u
Purpose:
Execute RCU callbacks in CONFIG_RCU_BOOST=y kernels.
To reduce its OS jitter, do at least one of the following:
1. Build the kernel with CONFIG_PREEMPT=n. This prevents these
kthreads from being created in the first place, and also obviates
the need for RCU priority boosting. This approach is feasible
for workloads that do not require high degrees of responsiveness.
2. Build the kernel with CONFIG_RCU_BOOST=n. This prevents these
kthreads from being created in the first place. This approach
is feasible only if your workload never requires RCU priority
boosting, for example, if you ensure frequent idle time on all
CPUs that might execute within the kernel.
3. Build with CONFIG_RCU_NOCB_CPU=y and boot with the rcu_nocbs=
boot parameter offloading RCU callbacks from all CPUs susceptible
to OS jitter. This approach prevents the rcuc/%u kthreads from
having any work to do, so that they are never awakened.
4. Ensure that the CPU never enters the kernel, and, in particular,
avoid initiating any CPU hotplug operations on this CPU. This is
another way of preventing any callbacks from being queued on the
CPU, again preventing the rcuc/%u kthreads from having any work
to do.
Name:
rcuop/%d, rcuos/%d, and rcuog/%d
Purpose:
Offload RCU callbacks from the corresponding CPU.
To reduce its OS jitter, do at least one of the following:
1. Use affinity, cgroups, or other mechanism to force these kthreads
to execute on some other CPU.
2. Build with CONFIG_RCU_NOCB_CPU=n, which will prevent these
kthreads from being created in the first place. However, please
note that this will not eliminate OS jitter, but will instead
shift it to RCU_SOFTIRQ.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
per-CPU kthread로 인한 OS jitter 줄이기
1-33이 문서는 Linux 커널의 per-CPU kthread를 나열하고, 이들이 일으키는 OS jitter를 제어하는 방법을 제시합니다. non-per-CPU kthread는 여기에 나열하지 않습니다. non-per-CPU kthread가 일으키는 OS jitter를 줄이려면 그런 작업 전용인 "housekeeping" CPU에 해당 thread를 bind하십시오.
참고 자료
| 자료 | 용도 |
|---|---|
| Documentation/core-api/irq/irq-affinity.rst | interrupt를 CPU 집합에 bind합니다. |
| Documentation/admin-guide/cgroup-v1 | cgroup을 사용해 task를 CPU 집합에 bind합니다. |
| man taskset | `taskset` 명령을 사용해 task를 CPU 집합에 bind합니다. |
| man sched_setaffinity | `sched_setaffinity()` system call을 사용해 task를 CPU 집합에 bind합니다. |
| /sys/devices/system/cpu/cpuN/online | CPU N의 hotplug 상태를 제어합니다. `0`을 쓰면 offline, `1`을 쓰면 online입니다. |
CPU N에서 커널이 생성한 OS jitter를 찾으려면 다음 절차를 사용합니다.
cd /sys/kernel/tracing
echo 1 > max_graph_depth # Increase the "1" for more detail
echo function_graph > current_tracer
# run workload
cat per_cpu/cpuN/traceeHCA, threaded IRQ와 Bluetooth kthread
34-79ehca_comp/%u
목적: Infiniband 관련 작업을 주기적으로 처리합니다.
OS jitter를 줄이려면 다음 방법 중 하나를 사용합니다. 1. eHCA Infiniband hardware를 사용하지 말고 per-CPU kthread가 필요 없는 hardware를 선택합니다. 그러면 이 kthread 자체가 생성되지 않습니다. 이 hardware는 중요하지만 비교적 오래되었고 생산량도 상대적으로 적으므로 대부분의 사용자에게 적용할 수 있습니다.
2. interrupt를 포함한 모든 eHCA-Infiniband 관련 작업을 다른 CPU에서 수행합니다.
3. eHCA driver를 수정하여 선택한 CPU에만 per-CPU kthread가 provision되도록 합니다.
irq/%d-%s
목적: threaded interrupt를 처리합니다.
OS jitter를 줄이려면 IRQ affinity를 사용하여 IRQ thread가 다른 CPU에서 실행되도록 강제합니다.
kcmtpd_ctr_%d
목적: Bluetooth 작업을 처리합니다.
OS jitter를 줄이려면 다음 중 하나를 사용합니다. 1. Bluetooth를 사용하지 않습니다. 그러면 이 kthread가 애초에 생성되지 않습니다.
2. IRQ affinity를 사용하여 Bluetooth 관련 interrupt가 다른 CPU에서 발생하도록 강제하고, 모든 Bluetooth 동작도 다른 CPU에서 시작합니다.
ksoftirqd와 TIMER_SOFTIRQ
80-104ksoftirqd/%u
목적: softirq가 threaded 방식으로 실행되거나 부하가 클 때 softirq handler를 실행합니다. OS jitter를 줄이려면 각 softirq vector를 아래와 같이 개별적으로 처리해야 합니다.
TIMER_SOFTIRQ
다음을 모두 수행합니다. 1. 가능한 한 non-idle 상태의 CPU가 커널에 들어가지 않게 합니다. 예를 들어 system call을 피하고, kernel thread와 interrupt가 모두 다른 곳에서 실행되도록 강제합니다.
2. `CONFIG_HOTPLUG_CPU=y`로 빌드합니다. 부팅이 끝나면 해당 CPU를 offline으로 강제한 뒤 다시 online으로 전환합니다. 그러면 반복 timer가 다른 곳으로 migrate됩니다. 여러 CPU가 대상이라면 첫 번째 CPU를 다시 online으로 만들기 전에 대상 CPU 모두를 offline으로 만듭니다. 대상 CPU를 online으로 만든 뒤에는 다른 CPU를 offline으로 만들지 마십시오. 그러면 timer가 대상 CPU 중 하나로 다시 이동할 수 있습니다.
network와 block I/O softirq
105-140NET_TX_SOFTIRQ와 NET_RX_SOFTIRQ
다음을 모두 수행합니다. 1. network interrupt를 다른 CPU로 강제합니다. 2. 모든 network I/O를 다른 CPU에서 시작합니다.
3. application이 시작된 뒤에는 jitter를 줄일 CPU에서 실행될 수 있는 task가 CPU-hotplug operation을 시작하지 못하게 합니다. application 시작 전이라면 이 CPU를 offline으로 강제한 뒤 다시 online으로 만드는 것은 괜찮습니다.
BLOCK_SOFTIRQ
다음을 모두 수행합니다. 1. block-device interrupt를 다른 CPU로 강제합니다. 2. 모든 block I/O를 다른 CPU에서 시작합니다.
3. application이 시작된 뒤에는 jitter를 줄일 CPU에서 실행될 수 있는 task가 CPU-hotplug operation을 시작하지 못하게 합니다. application 시작 전이라면 이 CPU를 offline으로 강제한 뒤 다시 online으로 만드는 것은 괜찮습니다.
IRQ_POLL_SOFTIRQ
다음을 모두 수행합니다. 1. block-device interrupt를 다른 CPU로 강제합니다. 2. 모든 block I/O와 block-I/O polling을 다른 CPU에서 시작합니다.
3. application이 시작된 뒤에는 jitter를 줄일 CPU에서 실행될 수 있는 task가 CPU-hotplug operation을 시작하지 못하게 합니다. application 시작 전이라면 이 CPU를 offline으로 강제한 뒤 다시 online으로 만드는 것은 괜찮습니다.
TASKLET_SOFTIRQ와 SCHED_SOFTIRQ
141-173TASKLET_SOFTIRQ
다음 중 하나 이상을 수행합니다. 1. tasklet을 사용하는 driver를 피합니다. 이런 driver에는 `tasklet_schedule()` 같은 호출이 들어 있습니다. 2. 반드시 사용해야 하는 모든 driver를 tasklet 방식에서 workqueue 방식으로 변환합니다.
3. tasklet을 사용하는 driver의 interrupt를 다른 CPU로 강제하고, 그 driver를 사용하는 I/O도 다른 CPU에서 수행합니다.
SCHED_SOFTIRQ
다음을 모두 수행합니다. 1. jitter를 줄일 CPU에 scheduler IPI를 보내지 않도록 합니다. 예를 들어 그 CPU에 runnable kthread가 최대 하나만 존재하도록 합니다. jitter를 줄일 CPU에서 실행될 것으로 예상되는 thread가 깨어나면 scheduler가 IPI를 보내며, 그 결과 뒤이어 `SCHED_SOFTIRQ`가 발생할 수 있습니다.
2. `CONFIG_NO_HZ_FULL=y`로 설정하고 `nohz_full=` boot parameter를 사용하여 jitter를 줄일 CPU를 adaptive-ticks CPU로 표시합니다. 그러면 해당 CPU가 받는 scheduler-clock interrupt 수가 줄어 `SCHED_SOFTIRQ` context에서 수행되는 load-balancing 작업 대상으로 선택될 가능성이 최소화됩니다.
3. 가능한 한 non-idle 상태의 CPU가 커널에 들어가지 않게 합니다. 예를 들어 system call을 피하고, kernel thread와 interrupt가 모두 다른 곳에서 실행되도록 강제합니다. 이렇게 하면 jitter를 줄일 CPU가 받는 scheduler-clock interrupt 수가 더 줄어듭니다.
HRTIMER_SOFTIRQ와 RCU_SOFTIRQ
174-220HRTIMER_SOFTIRQ
다음을 모두 수행합니다. 1. 가능한 한 non-idle 상태의 CPU가 커널에 들어가지 않게 합니다. 예를 들어 system call을 피하고, kernel thread와 interrupt가 모두 다른 곳에서 실행되도록 강제합니다.
2. `CONFIG_HOTPLUG_CPU=y`로 빌드합니다. 부팅이 끝나면 해당 CPU를 offline으로 강제한 뒤 다시 online으로 전환합니다. 그러면 반복 timer가 다른 곳으로 migrate됩니다. 여러 CPU가 대상이라면 첫 번째 CPU를 다시 online으로 만들기 전에 대상 CPU 모두를 offline으로 만듭니다. 대상 CPU를 online으로 만든 뒤에는 다른 CPU를 offline으로 만들지 마십시오. 그러면 timer가 대상 CPU 중 하나로 다시 이동할 수 있습니다.
RCU_SOFTIRQ
다음 중 적어도 하나를 수행합니다. 1. callback을 offload하고 다음을 모두 수행하여 CPU를 dyntick-idle 또는 adaptive-ticks 상태로 유지합니다.
1.a. `CONFIG_NO_HZ_FULL=y`로 설정하고 `nohz_full=` boot parameter를 사용하여 jitter를 줄일 CPU를 adaptive-ticks CPU로 표시합니다. `rcuo` kthread는 OS jitter를 감당할 수 있는 housekeeping CPU에 bind합니다.
1.b. 가능한 한 non-idle 상태의 CPU가 커널에 들어가지 않게 합니다. 예를 들어 system call을 피하고, kernel thread와 interrupt가 모두 다른 곳에서 실행되도록 강제합니다.
2. 다음을 모두 수행하여 RCU가 dyntick-idle을 통해 processing을 원격으로 수행하게 합니다. 2.a. `CONFIG_NO_HZ=y`로 빌드합니다.
2.b. CPU가 자주 idle 상태가 되게 하여 다른 CPU가 해당 CPU가 RCU quiescent state를 통과했음을 감지할 수 있게 합니다. 커널을 `CONFIG_NO_HZ_FULL=y`로 빌드했다면 userspace 실행도 다른 CPU가 해당 CPU의 quiescent state 통과를 감지하게 해 줍니다.
2.c. 가능한 한 non-idle 상태의 CPU가 커널에 들어가지 않게 합니다. 예를 들어 system call을 피하고, kernel thread와 interrupt가 모두 다른 곳에서 실행되도록 강제합니다.
kworker workqueue 요청의 jitter 제어
221-284kworker/%u:%d%s (cpu, id, priority)
목적: workqueue 요청을 실행합니다.
OS jitter를 줄이려면 다음 중 하나를 수행합니다. 1. workload를 real-time priority로 실행합니다. 그러면 kworker daemon을 preempt할 수 있습니다.
2. 특정 workqueue의 `alloc_workqueue()`에 `WQ_SYSFS`를 전달하면 그 workqueue를 sysfs에 노출할 수 있습니다. 그런 workqueue는 `/sys/devices/virtual/workqueue/*/cpumask` sysfs 파일을 사용하여 주어진 CPU subset으로 제한할 수 있습니다. `WQ_SYSFS` workqueue 집합은 `ls /sys/devices/virtual/workqueue`로 표시할 수 있습니다.
다만 workqueue maintainer는 모든 workqueue에 `WQ_SYSFS`를 무분별하게 추가하지 말라고 경고합니다. `WQ_SYSFS`를 추가하기는 쉽지만 sysfs는 정식 user/kernel API의 일부이므로, 추가가 실수였더라도 제거하기가 거의 불가능할 수 있기 때문입니다.
3. application이 감당할 수 없는 jitter를 피하려면 다음 중 필요한 조치를 수행합니다. 3.a. `oprofile`을 사용하지 않아 `wq_sync_buffer()`에서 생기는 OS jitter를 피합니다.
3.b. CPU-frequency governor가 필요 없도록 CPU frequency를 제한합니다. 필요하다면 특수 heatsink나 다른 cooling 기술을 사용합니다. 올바르게 구성했고 CPU architecture가 허용한다면 `CONFIG_CPU_FREQ=n`으로 커널을 빌드하여 `cs_dbs_timer()`와 `od_dbs_timer()`를 포함한 CPU-frequency governor가 각 CPU에서 주기적으로 실행되는 것을 막을 수 있습니다.
경고: 이 구성이 특정 시스템에서 안전한지 CPU specification을 반드시 확인하십시오.
3.c. v3.18부터 Christoph Lameter의 on-demand vmstat worker commit은 `CONFIG_SMP=y` 시스템에서 `vmstat_update()`가 일으키는 OS jitter를 방지합니다. v3.18 전에는 OS jitter를 완전히 없앨 수 없지만 `/proc/sys/vm/stat_interval`에 큰 값을 써서 빈도를 줄일 수 있습니다. 기본값은 `HZ`, 즉 1초 간격입니다. 값이 커질수록 virtual-memory 통계 갱신은 느려집니다.
workload를 real-time priority로 실행하여 `vmstat_update()`를 preempt할 수도 있지만 CPU-bound workload에는 좋지 않습니다. Christoph Lameter가 Gilad Ben-Yossef의 이전 patch를 바탕으로 작성한 RFC patch는 일부 workload에서 vmstat overhead를 줄이거나 없앱니다: https://lore.kernel.org/r/00000140e9dfd6bd-40db3d4f-c1be-434f-8132-7820f81bb586-000000@email.amazonses.com.
3.d. high-end powerpc server에서 실행한다면 `CONFIG_PPC_RTAS_DAEMON=n`으로 빌드합니다. 그러면 RTAS daemon이 각 CPU에서 약 1초마다 실행되지 않습니다. Kconfig 파일을 수정해야 하며 이 platform의 RAS 기능이 무효화됩니다. 이 방법은 `rtas_event_scan()` 함수가 일으키는 jitter를 피합니다.
경고: 이 구성이 특정 시스템에서 안전한지 CPU specification을 반드시 확인하십시오.
3.e. PowerMAC에서 실행한다면 `CONFIG_PMAC_RACKMETER=n`으로 커널을 빌드하여 CPU-meter를 비활성화하고 `rackmeter_do_timer()`가 일으키는 OS jitter를 피합니다.
rcuc/%u RCU callback thread
285-311rcuc/%u
목적: `CONFIG_RCU_BOOST=y` 커널에서 RCU callback을 실행합니다.
OS jitter를 줄이려면 다음 중 적어도 하나를 수행합니다. 1. `CONFIG_PREEMPT=n`으로 커널을 빌드합니다. 그러면 이 kthread가 애초에 생성되지 않고 RCU priority boosting도 필요 없어집니다. 높은 responsiveness가 필요 없는 workload에 적합합니다.
2. `CONFIG_RCU_BOOST=n`으로 커널을 빌드합니다. 그러면 이 kthread가 애초에 생성되지 않습니다. 이 방법은 workload에 RCU priority boosting이 전혀 필요하지 않은 경우에만 적합합니다. 예를 들어 커널 안에서 실행될 수 있는 모든 CPU가 자주 idle 상태가 되도록 보장하는 경우입니다.
3. `CONFIG_RCU_NOCB_CPU=y`로 빌드하고 `rcu_nocbs=` boot parameter로 부팅하여 OS jitter에 민감한 모든 CPU의 RCU callback을 offload합니다. 그러면 `rcuc/%u` kthread가 처리할 작업이 없어 절대로 깨어나지 않습니다.
4. 해당 CPU가 절대로 커널에 진입하지 않게 하고, 특히 이 CPU에서 CPU hotplug operation을 시작하지 않게 합니다. 이는 callback이 CPU에 enqueue되지 않게 하는 또 다른 방법이며, 역시 `rcuc/%u` kthread가 처리할 작업이 없어지게 합니다.
rcuop, rcuos, rcuog callback offload thread
312-325rcuop/%d, rcuos/%d, rcuog/%d
목적: 대응하는 CPU에서 RCU callback을 offload합니다.
OS jitter를 줄이려면 다음 중 적어도 하나를 수행합니다. 1. affinity, cgroup 또는 다른 mechanism을 사용하여 이 kthread가 다른 CPU에서 실행되도록 강제합니다.
2. `CONFIG_RCU_NOCB_CPU=n`으로 빌드하여 이 kthread가 애초에 생성되지 않게 합니다. 다만 이것은 OS jitter를 제거하는 것이 아니라 `RCU_SOFTIRQ`로 옮길 뿐입니다.
문서 범위와 추적
kernel-per-CPU-kthreads.rst:1-33housekeeping CPU 격리 원칙, 관련 문서와 function-graph trace 절차를 정리합니다.