Cgroup v2 controllers can be enabled in a subtree of the shared
hierarchy. That allows users to limit the number of cgroups with a
controller enabled to less than the total number of cgroups. [1]
There are costs for each cgroup. Kernel memory is used for each cgroup,
plus additional memory for each active controller in each cgroup. Some
kernel operations scale with the number of cgroups (with a given
controller enabled), so it can be desirable to minimize the number of
cgroups with that controller enabled.
This change allows each v2 controller configuration to specify a maximum
activation depth, past which the controller will not be activated deeper
in the Android cgroup v2 hierarchy. The hierarchy root is defined as
depth 0. MaxActivationDepth is the field name for this purpose for
controllers in the Controllers array under Cgroups2 in cgroups.json.
Here are two examples:
"MaxActivationDepth": 1
This will activate the controller in every per-application cgroup, but
not in the per-process cgroups below.
/sys/fs/cgroup depth=0 active=true (controller listed in cgroup.subtree_control)
/sys/fs/cgroup/uid_0 depth=1 active=true (controller NOT listed in cgroup.subtree_control)
/sys/fs/cgroup/uid_0/pid_100 depth=2 active=false (controller NOT listed in cgroup.subtree_control)
This can also be used with
PRODUCT_CGROUP_V2_SYS_APP_ISOLATION_ENABLED := true.
"MaxActivationDepth": 1
This will activate the controller only at the app / system level, but
not in per-application cgroups below. This results in a total of only
3 cgroups with the controller enabled (root, apps, system).
/sys/fs/cgroup depth=0 active=true (controller listed in cgroup.subtree_control)
/sys/fs/cgroup/apps depth=1 active=true (controller NOT listed in cgroup.subtree_control)
/sys/fs/cgroup/apps/uid_10000 depth=2 active=false (controller NOT listed in cgroup.subtree_control)
/sys/fs/cgroup/apps/uid_10000/pid_100 depth=3 active=false (controller NOT listed in cgroup.subtree_control)
[1] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#enabling-and-disabling
Bug: 346584259
Test: Cuttlefish with memcg v2
Change-Id: I62109ea935261c51fc30b2054c4d28d0360f7985
This flag prevents memcg from being mounted as a v1 hierarchy, even if
cgroups.json specifies it should be mounted as v1. It will activate
memcg in the v2 hierarchy even if cgroups.json does not specify that it
should be activated in the v2 hierarchy.
The cgroup_disable=memory kernel command line argument will still
prevent memcg from being activated, as this forced memcg controller
is marked as optional.
Bug: 327480673
Change-Id: Iad2491dd0c1576156ee2346928d041d85af890f0
Use CgroupController definition from libcgrouprc_format, not
libprocessgroup, because the wire format will be removed
from libprocessgroup later.
Bug: 123664216
Test: builds
Change-Id: If5e2301a1b65c3f6a51a1661cfeeed4e299f634e
Merged-In: If5e2301a1b65c3f6a51a1661cfeeed4e299f634e
Only init uses SetupCgroups. This functionality is
moved from libprocessgroup to its own library, and only
init links to it.
Also, merge CgroupSetupCgroups() with CgroupMap::SetupCgroups()
because the former is just an alias of the latter, and
CgroupMap does not belong to libcgrouprc_setup.
Test: boots
Bug: 123664216
Change-Id: I941dc0c415e2b22ae663d43e30dc7a464687325e
Merged-In: I941dc0c415e2b22ae663d43e30dc7a464687325e
