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: I3dadc0b7bccfe28bb067a93df2acf2c3ea0f9920
This was targeted for API 36 which doesn't exist yet, so this was never
released. Now that libprocessgroup does not use the libcgrouprc
interfaces, this can be removed.
Bug: 349105928
Bug: 359609093
Change-Id: I2ea466c9e8bc54bf9178fa74b45e88f26d3e4c69
Read cgroup descriptors ourselves instead of going through the LLNDK
interface which performs the same thing.
Bug: 349105928
Change-Id: I94625ffd0d884d619eb3449e63a305ad5e1d77e3
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
Schedtune was an out of tree cgroup controller present in Android
kernels up to 4.19. It was replaced with uclamp and the cpu controller.
Now that 4.19 is EOL and unsupported, and schedtune is not present in
any supported Android kernels, remove the userspace support for
schedtune.
Bug: 362504801
Change-Id: If8baaf1a616984c5dbaac1bbd03e23ad001bc29c
In multi-window mode, currently the focused window will be top-app,
and others will be foreground. However, the cpu resource we assign to
typical foreground group may not meet the performance need of those
windows. Therefore, create a new group for them so that we could
distinguish their performance need.
Bug: 200769420
Test: group created
Change-Id: I84c61f9ed4d167e156dafb7a816b6482e80a8523
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
SetupCgroups was moved from CgroupMap in libprocessgroup to SetupCgroup
in libprocessgroup_setup, but the old declaration was not removed.
Fixes: 6f9ce2e548 ("libprocessgroup: Move CgroupSetupCgroups() to libprocessgroup_setup")
Test: m
Change-Id: I9f85000392b59a105bb202fae277a5582449822a
These are for ACgroupController and ACgroupFile, but share a filename
with libcgrouprc_format's CgroupController which can be confusing.
Bug: 349105928
Test: m
Change-Id: Idb270068169b71b0a33101407ddbb5a38cc8d469
So that the name is not overloaded with libcgrouprc_format's
CgroupController, which can be confusing.
Bug: 349105928
Test: m
Change-Id: I39df9814c500de68fd20139e661363ba51ea3543
This reverts commit 104d3cc4b9.
Reason for revert: change from presubmit to presubmit-large
Bug: 349693967
Change-Id: I47ea41162aea0140bc460521d0638ce9ca8a96a3
This reverts commit 0509c71cc4.
Reason for revert: Droidmonitor triggered revert due to Test breakage in b/349693967. Will be verifying through ABTD before submission.
Change-Id: I66a706b8b4f9bf802f7ea1a6b50bb4847b915c92
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
* changes:
libprocessgroup: Check validity of uid and pid arguments for createProcessGroup
Revert "libprocessgroup: Check validity of uid and pid arguments"
killProcessGroup already checks for validity of the uid and pid input
arguments. Also add this checking to createProcessGroup.
Bug: 333261173
Change-Id: Ie74b9c2716978cb5eb434af12e27945e29af876e
This flag adds "apps" and "system" cgroups underneath the v2 hierarchy
root. Cgroups with UIDs < 10000 (AID_APP_START) will be placed
under "system" and others will be placed under "apps". UIDs under 10000
are reserved for core Android subsystems. This allows us to
apply different cgroup controls collectively to system processes and
normal applications.
Bug: 327480673
Change-Id: I40837dee27a59691f81fef48e66a86c5eacda892
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
We already get -Wall and -Werror from the build system, and we do not
want/need -Wexit-time-destructors since it prevents local statics with
non-trivial destructors.
Test: m
Change-Id: I8283bf223404d6c253861d3888c1b720c099386e
As of VNDK deprecation, any libraries that defines vndk is no longer
valid anymore. This change removes all VNDK definition(s) from modules
which was VNDK. Any former VNDK-SP libraries will be marked as double-loadable,
so it can keep be able to be referenced by LLNDK libraries.
Bug: 328994089
Test: AOSP CF build succeeded
Change-Id: I1662f16e5e446bb28167b0bb278cd63997267d2a
* changes:
libprocessgroup: Use pid_t consistently for TIDs
libprocessgroup: Use pid_t consistently for PIDs
libprocessgroup: Use uid_t consistently for UIDs
By using cgroup.kill we don't need to read cgroup.procs at all for
SIGKILLs, which is more efficient and should help reduce CPU contention
and cgroup lock contention. Fallback to cgroup.procs if we encounter an
error trying to use cgroup.kill, but if cgroup.kill fails it's likely
that cgroup.procs will too.
Bug: 239829790
Test: atest StagedRollbackTest:com.android.tests.rollback.host.StagedRollbackTest#testNativeWatchdogTriggersRebootlessApexRollback
Change-Id: I9da67efd00af49b7b4b502fb742c1095d5c7b9e9
This reverts commit a72332f953.
This change was originally reverted due to a bug in the child commit
which caused process group kills not to occur when using cgroup.kill.
Now that has been fixed, bring back this change with the fixed child.
Bug: 301871933
Change-Id: Ia6c74d9b67a8c88aec4812ac4655646934e0d189
This revert was created by Android Culprit Assistant. The culprit was identified in the following culprit search session (http://go/aca-get/91da3c52-9b76-498b-bdbd-a9de7d7ff53b).
Change-Id: I996c595bee9acc15aedaf0a912f67fa027f33cd0
This revert was created by Android Culprit Assistant. The culprit was identified in the following culprit search session (http://go/aca-get/91da3c52-9b76-498b-bdbd-a9de7d7ff53b).
Change-Id: I459265b9c9117d6006c1223947a202505d24c08f
By using cgroup.kill we don't need to read cgroup.procs at all for
SIGKILLs, which is more efficient and should help reduce CPU contention
and cgroup lock contention. Fallback to cgroup.procs if we encounter an
error trying to use cgroup.kill, but if cgroup.kill fails it's likely
that cgroup.procs will too.
Bug: 239829790
Change-Id: I44706faccfb7c4611b512a3642b913f06d30c1dc
In killProcessGroup we currently read cgroup.procs to find processes to
kill, send them kill signals until cgroup.procs is empty, then remove
the cgroup directory. The cgroup cannot be removed until all processes
are dead, otherwise we'll get an EBUSY error from the kernel.
There is a race in the kernel where cgroup.procs can read empty even
though the cgroup is pinned by processes which are still exiting, and
can't be removed yet. [1]
Let's use the populated field of cgroup.events instead of an empty
cgroup.procs file to determine when the cgroup is removable. In
addition to functioning like we expect, this is more efficient because
we can poll on cgroup.events instead of retrying kills and rereading
cgroup.procs every 5ms which should help reduce CPU contention and
cgroup lock contention.
It's still possible that it takes longer for a cgroup to become
unpopulated than our timeout allows, in which case we will fail to
remove the cgroup and leak kernel memory. But this change should help
reduce the probability of that happening.
[1] https://lore.kernel.org/all/CABdmKX3SOXpcK85a7cx3iXrwUj=i1yXqEz9i9zNkx8mB=ZXQ8A@mail.gmail.com/
Bug: 301871933
Change-Id: If7dcfb331f47e06994c9ac85ed08bbcce18cdad7
