Revert submission 3212512
Reason for revert: Droidmonitor created revert due to b/372273614. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3212512
Change-Id: I37568516e973cb940f1229d52f94b8dc801da2ab
The cgroup.rc file was introduced in 192aee782 ("libprocessgroup: Add
support for task profiles") back with the initial support for task
profiles. It was intended to optimize performance associated with cgroup
operations. However over time, supporting this file led to making
libprocessgroup code more complicated (such as the cgrouprc LLNDK
interface), and the file ended up getting mmaped into nearly every
process on Android even though only a handful of them actually use it.
Replacing this file with reading and parsing of cgroup information on
demand allows us to simplify and shrink libprocessgroup, and eliminates
thousands of unused mappings without negatively affecting boot time or
other performance metrics.
Bug: 349105928
Test: Verified with memcg v2 and MaxActivationDepth 1 on Cuttlefish, Raven, and Mokey
Change-Id: Ic3f01fdf7fda89a56ab80657e1cf4573156273e6
To avoid duplicate symbol linker error and prep for addition of json
descriptor reading and activation functions in upcoming changes.
Bug: 349105928
Test: m
Change-Id: I5cd663d6007ef330b872b8cf8ed046ee68b6d736
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
