Documentation/core-api/housekeeping.rst
Source file repositories/reference/linux-study-clean/Documentation/core-api/housekeeping.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/core-api/housekeeping.rst- Extension
.rst- Size
- 4188 bytes
- Lines
- 112
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
======================================
Housekeeping
======================================
CPU Isolation moves away kernel work that may otherwise run on any CPU.
The purpose of its related features is to reduce the OS jitter that some
extreme workloads can't stand, such as in some DPDK usecases.
The kernel work moved away by CPU isolation is commonly described as
"housekeeping" because it includes ground work that performs cleanups,
statistics maintainance and actions relying on them, memory release,
various deferrals etc...
Sometimes housekeeping is just some unbound work (unbound workqueues,
unbound timers, ...) that gets easily assigned to non-isolated CPUs.
But sometimes housekeeping is tied to a specific CPU and requires
elaborate tricks to be offloaded to non-isolated CPUs (RCU_NOCB, remote
scheduler tick, etc...).
Thus, a housekeeping CPU can be considered as the reverse of an isolated
CPU. It is simply a CPU that can execute housekeeping work. There must
always be at least one online housekeeping CPU at any time. The CPUs that
are not isolated are automatically assigned as housekeeping.
Housekeeping is currently divided in four features described
by the ``enum hk_type type``:
1. HK_TYPE_DOMAIN matches the work moved away by scheduler domain
isolation performed through ``isolcpus=domain`` boot parameter or
isolated cpuset partitions in cgroup v2. This includes scheduler
load balancing, unbound workqueues and timers.
2. HK_TYPE_KERNEL_NOISE matches the work moved away by tick isolation
performed through ``nohz_full=`` or ``isolcpus=nohz`` boot
parameters. This includes remote scheduler tick, vmstat and lockup
watchdog.
3. HK_TYPE_MANAGED_IRQ matches the IRQ handlers moved away by managed
IRQ isolation performed through ``isolcpus=managed_irq``.
4. HK_TYPE_DOMAIN_BOOT matches the work moved away by scheduler domain
isolation performed through ``isolcpus=domain`` only. It is similar
to HK_TYPE_DOMAIN except it ignores the isolation performed by
cpusets.
Housekeeping cpumasks
=================================
Housekeeping cpumasks include the CPUs that can execute the work moved
away by the matching isolation feature. These cpumasks are returned by
the following function::
const struct cpumask *housekeeping_cpumask(enum hk_type type)
By default, if neither ``nohz_full=``, nor ``isolcpus``, nor cpuset's
isolated partitions are used, which covers most usecases, this function
returns the cpu_possible_mask.
Otherwise the function returns the cpumask complement of the isolation
feature. For example:
With isolcpus=domain,7 the following will return a mask with all possible
CPUs except 7::
housekeeping_cpumask(HK_TYPE_DOMAIN)
Similarly with nohz_full=5,6 the following will return a mask with all
possible CPUs except 5,6::
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.