Documentation/admin-guide/cgroup-v1/cgroups.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/cgroup-v1/cgroups.rst

File Facts

System: Linux kernel
Corpus path: Documentation/admin-guide/cgroup-v1/cgroups.rst
Extension: .rst
Size: 27043 bytes
Lines: 698
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

==============
Control Groups
==============

Written by Paul Menage <menage@google.com> based on
Documentation/admin-guide/cgroup-v1/cpusets.rst

Original copyright statements from cpusets.txt:

Portions Copyright (C) 2004 BULL SA.

Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.

Modified by Paul Jackson <pj@sgi.com>

Modified by Christoph Lameter <cl@gentwo.org>

.. CONTENTS:

	1. Control Groups
	1.1 What are cgroups ?
	1.2 Why are cgroups needed ?
	1.3 How are cgroups implemented ?
	1.4 What does notify_on_release do ?
	1.5 What does clone_children do ?
	1.6 How do I use cgroups ?
	2. Usage Examples and Syntax
	2.1 Basic Usage
	2.2 Attaching processes
	2.3 Mounting hierarchies by name
	3. Kernel API
	3.1 Overview
	3.2 Synchronization
	3.3 Subsystem API
	4. Extended attributes usage
	5. Questions

1. Control Groups
=================

1.1 What are cgroups ?
----------------------

Control Groups provide a mechanism for aggregating/partitioning sets of
tasks, and all their future children, into hierarchical groups with
specialized behaviour.

Definitions:

A *cgroup* associates a set of tasks with a set of parameters for one
or more subsystems.

A *subsystem* is a module that makes use of the task grouping
facilities provided by cgroups to treat groups of tasks in
particular ways. A subsystem is typically a "resource controller" that
schedules a resource or applies per-cgroup limits, but it may be
anything that wants to act on a group of processes, e.g. a
virtualization subsystem.

A *hierarchy* is a set of cgroups arranged in a tree, such that
every task in the system is in exactly one of the cgroups in the
hierarchy, and a set of subsystems; each subsystem has system-specific
state attached to each cgroup in the hierarchy.  Each hierarchy has
an instance of the cgroup virtual filesystem associated with it.

At any one time there may be multiple active hierarchies of task
cgroups. Each hierarchy is a partition of all tasks in the system.

User-level code may create and destroy cgroups by name in an
instance of the cgroup virtual file system, specify and query to

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.