From nobody Thu Oct 2 16:59:03 2025 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B08F2EDD69 for ; Mon, 15 Sep 2025 08:19:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757924401; cv=none; b=Y9DaK6sNqx4HTzZRWkOOHvaeN2h0RSKbGIX3/JQT9V9tf36KDayqbsWWP+mheIQU7F8HTgN8P0tFYMNucuG3MUZHX9CMvUiZshl99hT404aDXUSc7xGl10jcl8ljjqTiMB4iTGTtq4V6fhvVJ81chl+jnie1uZXaTBFYd5O6JfA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757924401; c=relaxed/simple; bh=pYgWUUKXe3JWPoQ3EuJX2eOqpXAmM/Cmsyg27j/8/bs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fWYo5DfGEug4RMaq9gPpdvS3kaPVAWPCX9G1w/cmiLGUD0eBRTATttcADFiisfOCDN5suXyIYo4muSC5luXlOD7nCbQbtKmClXa/PyKwlBE7fNrxY0jLhk0DijvZDrlr6Y+73tUdv2BOFpQUfDvWe6dvCiYOdxqe/SjUlNYB0y8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jLWJE2h0; arc=none smtp.client-ip=209.85.210.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jLWJE2h0" Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-76e4f2e4c40so3300181b3a.2 for ; Mon, 15 Sep 2025 01:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757924398; x=1758529198; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RUaDtBTQV0zd0yXQ6ReLCoQtRfP5AzMgI7L4iFOt2Rg=; b=jLWJE2h0Zf7efveYTCwfh+IWUBqwXwET7Uq6/4oR4MveTnTL4ZwCu9wgOSTwmuuc3Q a4f6vVnTGMU5p2egn4saoUPwwR5LN/BL0/0zIZE3bB6NNVLR0qtjy6Mh0v9AneiBYl/Z 8r2yzqkEfKNrFPx7stdJm8aRCQyknIqDRcKON94PRCbHcZSLwoP7PxOjzBYhwt2aiOsT y4PQfjU6f4Evk/0LYVC1Y+6EgaZJxD/JurcQYPV4yPkA5FwX59foN9EaBAIch2J2aynl F1mbkvccqbKET2/rg8DZF0I4xBVRfMi2j1rn2se9kEkqubu5eJpr4MAaENb3lXsA9Pz2 N9JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757924398; x=1758529198; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RUaDtBTQV0zd0yXQ6ReLCoQtRfP5AzMgI7L4iFOt2Rg=; b=bteC5Y6UXkochsZ2rmFlwLtfpSAvFwv5tkcFa7e6t9uKjvCX6Wn4ZSPELHG/AMYcBt qS6RFHeSJLME8xAHSKkrauv8XIw1QVuk55rww7aIGeJwLm0BSka/YBr19cGvPZgHRWD3 1JOshSdQuTY16DJE6hsKZcNCnCoMJJ7ETevBtAXOPCozf54hexLsLUBC4fU0J5pbeUt0 XLODGzaZvJAuG6Ds5rXwiBIhCYZhgorwOaS42mQNmyToEm1CPfcqhxqnhh3vz9Vkg0ez uWiLs0hPPxGK7Z0sjY4S3RcyVkdwrZlNWqtyJ2OAc2hDQWwrbEyF4FYeg9b0RlWUkX0R nsrQ== X-Gm-Message-State: AOJu0YxzEbdPyq6Ybgw5vaFyp9O5EOwuRPlO9vY5tJqbbkXE+PKQV1wp GwFBwqh3UbR7Osx1wFCm/CQLxxNv3Y3QVhr2/KxCCW35Jtir9GV55ah3 X-Gm-Gg: ASbGncsI1zuvYqkHeEhmKIHW79ixd6BiplMN4zKzVpb+iUmzBv5vzNV/syCxzlw6yYx S3Xc6XNFjUqn0LSHthOaNZuDHo6vNi2FPMinYbJyu0gMnj3+73dwI7kr5ubQ+ZHz6gV7cdj8tA1 qU4JhgDn004FiBfDUvabmAkEHnbZOVIaZqIg1lsxGyU8OUohMoXCdxmLjPFurYo77yQz4o9wLbR necxty6GQchumGRkZsVJEWs4x/e2yRw1Ib496YFRsSXT7cQJXgZEBj40Qv+P6LVryA78UYOK/g0 WfpmzeYFYjToUExQ/Lj+RcRrj9Pr+9cwRbA0yXg62a2Wd/xa1O0B3jH6IWSE7H7iZfNbHRXucS0 DeZhvNzyob/TYcPKQpjwhQm4RY4ePyxOJZGO0 X-Google-Smtp-Source: AGHT+IEof1KUyWKHZqB6HF48Aikw3xXhLStAL8yIPxdIv4lh/c+onWEV5Kv2voPmTQ0ftIK1LyQHnw== X-Received: by 2002:a05:6a20:6a10:b0:24e:c235:d7e6 with SMTP id adf61e73a8af0-26029ea90c7mr14499319637.5.1757924397224; Mon, 15 Sep 2025 01:19:57 -0700 (PDT) Received: from archie.me ([103.124.138.155]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b54b03cf65csm8045746a12.16.2025.09.15.01.19.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Sep 2025 01:19:54 -0700 (PDT) Received: by archie.me (Postfix, from userid 1000) id 2307941FA3A1; Mon, 15 Sep 2025 15:19:48 +0700 (WIB) From: Bagas Sanjaya To: Linux Kernel Mailing List , Linux Documentation , Linux cgroups Cc: Jonathan Corbet , =?UTF-8?q?Michal=20Koutn=C3=BD?= , "Bagas Sanjaya" , Tejun Heo , Johannes Weiner , Andrea Righi , Johannes Bechberger , Changwoo Min , Shashank Balaji , Ingo Molnar , Jake Rice , Cengiz Can , "Mauro Carvalho Chehab" Subject: [PATCH v2 2/4] Documentation: cgroup-v2: Add section numbers Date: Mon, 15 Sep 2025 15:19:25 +0700 Message-ID: <20250915081942.25077-3-bagasdotme@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20250915081942.25077-1-bagasdotme@gmail.com> References: <20250915081942.25077-1-bagasdotme@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=25034; i=bagasdotme@gmail.com; h=from:subject; bh=pYgWUUKXe3JWPoQ3EuJX2eOqpXAmM/Cmsyg27j/8/bs=; b=owGbwMvMwCX2bWenZ2ig32LG02pJDBnHT+c92vVLrr4udaXtqldTSs/9+lfq/eCBtX6s6kVZp rvRq0p2dJSyMIhxMciKKbJMSuRrOr3LSORC+1pHmDmsTCBDGLg4BWAiO/cxMuzunl7camV2Z7Jk 6IzS+1UKEzY9vWS7br/pRrM/175vuP6E4X/VVvfDXc0Flx4y7uTsPHHZwLBtvWwkx/om20bxRUF 1GWwA X-Developer-Key: i=bagasdotme@gmail.com; a=openpgp; fpr=701B806FDCA5D3A58FFB8F7D7C276C64A5E44A1D Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Add section numbers, following the numbering scheme in the manual toctree. Note that sectnum:: directive cannot be used as it also numbers the docs title. Signed-off-by: Bagas Sanjaya --- Documentation/admin-guide/cgroup-v2.rst | 308 ++++++++++++------------ 1 file changed, 154 insertions(+), 154 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-= guide/cgroup-v2.rst index c3979661d95cd9..fe8ac5aa0f1ec9 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -92,11 +92,11 @@ v1 is available under :ref:`Documentation/admin-guide/c= group-v1/index.rst ` for details. =20 -Controllers -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +5. Controllers +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 .. _cgroup-v2-cpu: =20 -CPU ---- +5.1. CPU +-------- =20 The "cpu" controllers regulates distribution of CPU cycles. This controller implements weight and absolute bandwidth limit models for @@ -1119,8 +1119,8 @@ CONFIG_RT_GROUP_SCHED. Other controllers can be used = for the resource control of realtime processes irrespective of CONFIG_RT_GROUP_SCHED. =20 =20 -CPU Interface Files -~~~~~~~~~~~~~~~~~~~ +5.1.1. CPU Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 The interaction of a process with the cpu controller depends on its schedu= ling policy and the underlying scheduler. From the point of view of the cpu con= troller, @@ -1261,8 +1261,8 @@ will be referred to. All time durations are in micros= econds. =20 This file affects only processes under the fair-class scheduler. =20 -Memory ------- +5.2. Memory +----------- =20 The "memory" controller regulates distribution of memory. Memory is stateful and implements both limit and protection models. Due to the @@ -1284,8 +1284,8 @@ following types of memory usages are tracked. The above list may expand in the future for better coverage. =20 =20 -Memory Interface Files -~~~~~~~~~~~~~~~~~~~~~~ +5.2.1. Memory Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 All memory amounts are in bytes. If a value which is not aligned to PAGE_SIZE is written, the value may be rounded up to the closest @@ -1906,8 +1906,8 @@ The following nested keys are defined. :ref:`Documentation/accounting/psi.rst ` for details. =20 =20 -Usage Guidelines -~~~~~~~~~~~~~~~~ +5.2.2. Usage Guidelines +~~~~~~~~~~~~~~~~~~~~~~~ =20 "memory.high" is the main mechanism to control memory usage. Over-committing on high limit (sum of high limits > available memory) @@ -1930,8 +1930,8 @@ memory; unfortunately, memory pressure monitoring mec= hanism isn't implemented yet. =20 =20 -Memory Ownership -~~~~~~~~~~~~~~~~ +5.2.3. Memory Ownership +~~~~~~~~~~~~~~~~~~~~~~~ =20 A memory area is charged to the cgroup which instantiated it and stays charged to the cgroup until the area is released. Migrating a process @@ -1949,8 +1949,8 @@ POSIX_FADV_DONTNEED to relinquish the ownership of me= mory areas belonging to the affected files to ensure correct memory ownership. =20 =20 -IO --- +5.3. IO +------- =20 The "io" controller regulates the distribution of IO resources. This controller implements both weight based and absolute bandwidth or IOPS @@ -1959,8 +1959,8 @@ only if cfq-iosched is in use and neither scheme is a= vailable for blk-mq devices. =20 =20 -IO Interface Files -~~~~~~~~~~~~~~~~~~ +5.3.1. IO Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~ =20 io.stat A read-only nested-keyed file. @@ -2145,8 +2145,8 @@ IO Interface Files :ref:`Documentation/accounting/psi.rst ` for details. =20 =20 -Writeback -~~~~~~~~~ +5.3.2. Writeback +~~~~~~~~~~~~~~~~ =20 Page cache is dirtied through buffered writes and shared mmaps and written asynchronously to the backing filesystem by the writeback @@ -2205,8 +2205,8 @@ writeback as follows. vm.dirty[_background]_ratio. =20 =20 -IO Latency -~~~~~~~~~~ +5.3.3. IO Latency +~~~~~~~~~~~~~~~~~ =20 This is a cgroup v2 controller for IO workload protection. You provide a = group with a latency target, and if the average latency exceeds that target the @@ -2232,8 +2232,8 @@ avg_lat value in io.stat for your workload group to g= et an idea of the latency you see during normal operation. Use the avg_lat value as a basis= for your real setting, setting at 10-15% higher than the value in io.stat. =20 -How IO Latency Throttling Works -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +5.3.3.1. How IO Latency Throttling Works +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =20 io.latency is work conserving; so as long as everybody is meeting their la= tency target the controller doesn't do anything. Once a group starts missing its @@ -2258,8 +2258,8 @@ Once the victimized group starts meeting its latency = target again it will start unthrottling any peer groups that were throttled previously. If the victi= mized group simply stops doing IO the global counter will unthrottle appropriate= ly. =20 -IO Latency Interface Files -~~~~~~~~~~~~~~~~~~~~~~~~~~ +5.3.3.2. IO Latency Interface Files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =20 io.latency This takes a similar format as the other controllers. @@ -2284,8 +2284,8 @@ IO Latency Interface Files duration of time between evaluation events. Windows only elapse with IO activity. Idle periods extend the most recent window. =20 -IO Priority -~~~~~~~~~~~ +5.3.4. IO Priority +~~~~~~~~~~~~~~~~~~ =20 A single attribute controls the behavior of the I/O priority cgroup policy, namely the io.prio.class attribute. The following values are accepted for @@ -2346,8 +2346,8 @@ The algorithm to set the I/O priority class for a req= uest is as follows: into the maximum of the I/O priority class policy number and the numeric= al I/O priority class. =20 -PID ---- +5.4. PID +-------- =20 The process number controller is used to allow a cgroup to stop any new tasks from being fork()'d or clone()'d after a specified limit is @@ -2362,8 +2362,8 @@ Note that PIDs used in this controller refer to TIDs,= process IDs as used by the kernel. =20 =20 -PID Interface Files -~~~~~~~~~~~~~~~~~~~ +5.4.1. PID Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 pids.max A read-write single value file which exists on non-root @@ -2406,8 +2406,8 @@ through fork() or clone(). These will return -EAGAIN = if the creation of a new process would cause a cgroup policy to be violated. =20 =20 -Cpuset ------- +5.5. Cpuset +----------- =20 The "cpuset" controller provides a mechanism for constraining the CPU and memory node placement of tasks to only the resources @@ -2421,8 +2421,8 @@ The "cpuset" controller is hierarchical. That means = the controller cannot use CPUs or memory nodes not allowed in its parent. =20 =20 -Cpuset Interface Files -~~~~~~~~~~~~~~~~~~~~~~ +5.5.1. Cpuset Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 cpuset.cpus A read-write multiple values file which exists on non-root @@ -2679,8 +2679,8 @@ Cpuset Interface Files into a partition, they have to be used in an isolated partition. =20 =20 -Device controller ------------------ +5.6. Device controller +---------------------- =20 Device controller manages access to device files. It includes both creation of new device files (using mknod), and access to the @@ -2703,14 +2703,14 @@ An example of BPF_PROG_TYPE_CGROUP_DEVICE program m= ay be found in tools/testing/selftests/bpf/progs/dev_cgroup.c in the kernel source tree. =20 =20 -RDMA ----- +5.7. RDMA +--------- =20 The "rdma" controller regulates the distribution and accounting of RDMA resources. =20 -RDMA Interface Files -~~~~~~~~~~~~~~~~~~~~ +5.7.1. RDMA Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 rdma.max A readwrite nested-keyed file that exists for all the cgroups @@ -2742,15 +2742,15 @@ RDMA Interface Files mlx4_0 hca_handle=3D1 hca_object=3D20 ocrdma1 hca_handle=3D1 hca_object=3D23 =20 -DMEM ----- +5.8. DMEM +--------- =20 The "dmem" controller regulates the distribution and accounting of device memory regions. Because each memory region may have its own page si= ze, which does not have to be equal to the system page size, the units are alw= ays bytes. =20 -DMEM Interface Files -~~~~~~~~~~~~~~~~~~~~ +5.8.1. DMEM Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 dmem.max, dmem.min, dmem.low A readwrite nested-keyed file that exists for all the cgroups @@ -2785,14 +2785,14 @@ DMEM Interface Files drm/0000:03:00.0/vram0 12550144 drm/0000:03:00.0/stolen 8650752 =20 -HugeTLB -------- +5.9. HugeTLB +------------ =20 The HugeTLB controller allows to limit the HugeTLB usage per control group= and enforces the controller limit during page fault. =20 -HugeTLB Interface Files -~~~~~~~~~~~~~~~~~~~~~~~ +5.9.1. HugeTLB Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 hugetlb..current Show current usage for "hugepagesize" hugetlb. It exists for all @@ -2818,8 +2818,8 @@ HugeTLB Interface Files hugetlb pages of in this cgroup. Only active in use hugetlb pages are included. The per-node values are in bytes. =20 -Misc ----- +5.10. Misc +---------- =20 The Miscellaneous cgroup provides the resource limiting and tracking mechanism for the scalar resources which cannot be abstracted like the oth= er @@ -2835,8 +2835,8 @@ Once a capacity is set then the resource usage can be= updated using charge and uncharge APIs. All of the APIs to interact with misc controller are in include/linux/misc_cgroup.h. =20 -Misc Interface Files -~~~~~~~~~~~~~~~~~~~~ +5.10.1. Misc Interface Files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 Miscellaneous controller provides 3 interface files. If two misc resources= (res_a and res_b) are registered then: =20 @@ -2900,19 +2900,19 @@ Miscellaneous controller provides 3 interface files= . If two misc resources (res_ cgroup i.e. not hierarchical. The file modified event generated on this file reflects only the local events. =20 -Migration and Ownership -~~~~~~~~~~~~~~~~~~~~~~~ +5.10.2. Migration and Ownership +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 A miscellaneous scalar resource is charged to the cgroup in which it is us= ed first, and stays charged to that cgroup until that resource is freed. Migr= ating a process to a different cgroup does not move the charge to the destination cgroup where the process has moved. =20 -Others ------- +5.11. Others +------------ =20 -perf_event -~~~~~~~~~~ +5.11.1. perf_event +~~~~~~~~~~~~~~~~~~ =20 perf_event controller, if not mounted on a legacy hierarchy, is automatically enabled on the v2 hierarchy so that perf events can @@ -2920,15 +2920,15 @@ always be filtered by cgroup v2 path. The controll= er can still be moved to a legacy hierarchy after v2 hierarchy is populated. =20 =20 -Non-normative information -------------------------- +5.N. Non-normative information +------------------------------ =20 This section contains information that isn't considered to be a part of the stable kernel API and so is subject to change. =20 =20 -CPU controller root cgroup process behaviour -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +5.N.1. CPU controller root cgroup process behaviour +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 When distributing CPU cycles in the root cgroup each thread in this cgroup is treated as if it was hosted in a separate child cgroup of the @@ -2940,8 +2940,8 @@ kernel/sched/core.c file (values from this array shou= ld be scaled appropriately so the neutral - nice 0 - value is 100 instead of 1024). =20 =20 -IO controller root cgroup process behaviour -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +5.N.2. IO controller root cgroup process behaviour +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 Root cgroup processes are hosted in an implicit leaf child node. When distributing IO resources this implicit child node is taken into @@ -2949,11 +2949,11 @@ account as if it was a normal child cgroup of the r= oot cgroup with a weight value of 200. =20 =20 -Namespace -=3D=3D=3D=3D=3D=3D=3D=3D=3D +6. Namespace +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -Basics ------- +6.1. Basics +----------- =20 cgroup namespace provides a mechanism to virtualize the view of the "/proc/$PID/cgroup" file and cgroup mounts. The CLONE_NEWCGROUP clone @@ -3000,8 +3000,8 @@ namespace is destroyed. The cgroupns root and the ac= tual cgroups remain. =20 =20 -The Root and Views ------------------- +6.2. The Root and Views +----------------------- =20 The 'cgroupns root' for a cgroup namespace is the cgroup in which the process calling unshare(2) is running. For example, if a process in @@ -3050,8 +3050,8 @@ Note that the relative path always starts with '/' to= indicate that its relative to the cgroup namespace root of the caller. =20 =20 -Migration and setns(2) ----------------------- +6.3. Migration and setns(2) +--------------------------- =20 Processes inside a cgroup namespace can move into and out of the namespace root if they have proper access to external cgroups. For @@ -3079,8 +3079,8 @@ namespace. It is expected that the someone moves the= attaching process under the target cgroup namespace root. =20 =20 -Interaction with Other Namespaces ---------------------------------- +6.4. Interaction with Other Namespaces +-------------------------------------- =20 Namespace specific cgroup hierarchy can be mounted by a process running inside a non-init cgroup namespace:: @@ -3096,16 +3096,16 @@ the view of cgroup hierarchy by namespace-private c= groupfs mount provides a properly isolated cgroup view inside the container. =20 =20 -Information on Kernel Programming -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D +P. Information on Kernel Programming +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 This section contains kernel programming information in the areas where interacting with cgroup is necessary. cgroup core and controllers are not covered. =20 =20 -Filesystem Support for Writeback --------------------------------- +P.1. Filesystem Support for Writeback +------------------------------------- =20 A filesystem can support cgroup writeback by updating address_space_operations->writepages() to annotate bio's using the @@ -3139,8 +3139,8 @@ cases by skipping wbc_init_bio() and using bio_associ= ate_blkg() directly. =20 =20 -Deprecated v1 Core Features -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D +D. Deprecated v1 Core Features +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =20 - Multiple hierarchies including named ones are not supported. =20 @@ -3154,11 +3154,11 @@ Deprecated v1 Core Features "cgroup.stat" files at the root instead. =20 =20 -Issues with v1 and Rationales for v2 -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +R. Issues with v1 and Rationales for v2 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -Multiple Hierarchies --------------------- +R.1. Multiple Hierarchies +------------------------- =20 cgroup v1 allowed an arbitrary number of hierarchies and each hierarchy could host any number of controllers. While this seemed to @@ -3210,8 +3210,8 @@ how memory is distributed beyond a certain level whil= e still wanting to control how CPU cycles are distributed. =20 =20 -Thread Granularity ------------------- +R.2. Thread Granularity +----------------------- =20 cgroup v1 allowed threads of a process to belong to different cgroups. This didn't make sense for some controllers and those controllers @@ -3254,8 +3254,8 @@ misbehaving and poorly abstracted interfaces and kern= el exposing and locked into constructs inadvertently. =20 =20 -Competition Between Inner Nodes and Threads -------------------------------------------- +R.3. Competition Between Inner Nodes and Threads +------------------------------------------------ =20 cgroup v1 allowed threads to be in any cgroups which created an interesting problem where threads belonging to a parent cgroup and its @@ -3295,8 +3295,8 @@ This clearly is a problem which needs to be addressed= from cgroup core in a uniform way. =20 =20 -Other Interface Issues ----------------------- +R.4. Other Interface Issues +--------------------------- =20 cgroup v1 grew without oversight and developed a large number of idiosyncrasies and inconsistencies. One issue on the cgroup core side @@ -3324,11 +3324,11 @@ cgroup v2 establishes common conventions where appr= opriate and updates controllers so that they expose minimal and consistent interfaces. =20 =20 -Controller Issues and Remedies ------------------------------- +R.5. Controller Issues and Remedies +----------------------------------- =20 -Memory -~~~~~~ +R.5.1. Memory +~~~~~~~~~~~~~ =20 The original lower boundary, the soft limit, is defined as a limit that is per default unset. As a result, the set of cgroups that --=20 An old man doll... just what I always wanted! - Clara