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
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
Manually calling a defaulted default constructor from a another
constructor is superfluous, and can increase code size if the default
constructor is not otherwise used. There's nothing to delegate, so
remove the call.
Bug: 346584259
Test: m
Change-Id: Ia16aa041fdee7434587cf90645d7f95cba4e0d10
... instead of direct initialization in the default constructor
implementation. This allows us to just explicitly default the
constructor and provide no implementation.
Initialize class variables in the header and remove no-op constructor
to simplify code.
Bug: 346584259
Test: m
Change-Id: Iba57f5cfbf8e4d5d18ce178d39f8bcd2d76c8aaa
Controllers listed in cgroups.json file might fail to mount if kernel is
not configured to support them. We need a way to indicate whether a
controller was successfully mounted and is usable to avoid logging errors
and warnings when a controller that failed to mount is being used. Add
flags bitmask to cgrouprc controller descriptor and use a bit to indicate
that controller is successfully mounted. Modify cpusets_enabled() and
schedboost_enabled() functions to use this bit and report the actual
availability of the controller.
Bug: 124080437
Test: libcutils_test with cpuset and schedtune controllers disabled
Change-Id: I770cc39fe50465146e3205aacf77dc3c56923c5d
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Android build system added support for building translated binaries
used on natively bridged targets (arm on x86 for example).
However in order to avoid building unnecessary binaries and libraries
for such architectures most modules do not support native bridge by default.
All needed modules have to explicitly indicate if they may be used as part
of translated binary build.
This change enabled native bridge support for libprocessgroup modules
needed by libutils greylisted library (available for apps targeting
Android version < N).
Bug: http://b/77159578
Test: make
Change-Id: I8d6f33e95e9f7424f5fa12f6fbabafa1d6c37413
This module defines the wire format of the mmap()ed cgroup.rc
file.
Test: builds
Bug: 123664216
Change-Id: Iaf6199f759a6264590b13ca7ba6d7f576c3ed56a
Merged-In: Iaf6199f759a6264590b13ca7ba6d7f576c3ed56a
