This appears to have been due to the use of prctl, which apparently
caused issues for mac builds. Now that use of prctl has been removed, it
doesn't look like we need this anymore.
Fixes: 075008174 ("libprocessgroup: Remove prctl interface for setting timer slack")
Test: m
Bug: 372498744
Change-Id: I8a43951f30d7dd838591a8ba225d712742d7cd4a
These libbase functions now directly pass through to the standard
library. [1] Use the standard library directly, and eliminate this
dependency on libbase.
[1] https://r.android.com/c/platform/system/libbase/+/3315082
Change-Id: I83d79ffa2658f30ae09a7f27cedf14e62b5df41d
Add a new profile action that allows users to set a scheduler policy and
priority for a thread when a profile with the action is applied. This
can be used with the POSIX policies specified in the sched_setscheduler
man page. A priority value is required for real-time policies. A nice
value may optionally be provided for normal policies.
If a normal policy is used and a nice value is provided, it will be
applied with setpriority() after the scheduler policy is applied. The
range of nice values that can be used in the task profiles JSON in this
case is [-20, 19].
If a real-time policy is used, the range of priorities that can be used
in the task profiles JSON is [1, 99] which will be mapped onto
[sched_get_priority_min(), sched_get_priority_max()] at runtime for the
the provided policy.
Here are some examples:
Use lowest-priority with FIFO policy:
"Actions": [
{
"Name": "SetSchedulerPolicy",
"Params":
{
"Policy": "SCHED_FIFO",
"Priority": 1
}
}
]
Use highest-priority (lowest nice) with standard NORMAL scheduler:
"Actions": [
{
"Name": "SetSchedulerPolicy",
"Params":
{
"Policy": "SCHED_OTHER",
"Nice": -20
}
}
]
Bug: 368072932
BYPASS_INCLUSIVE_LANGUAGE_REASON=false positive
Change-Id: I502ceb3913016e9f4e6b6322cc0eee905c9a5c9a
The SetClamps profile action has always been a no-op. Remove the class
and parsing code for this action.
Bug: 372915523
Change-Id: Ic6e685aa992b83464dfb5e6446b622a57ed61db5
Support for the procfs timerslack interface has existed since linux 4.6.
All currently supported Android kernels are newer than 4.6, so remove
the userspace support for the prctl interface leaving just the use of
/proc/<tid>/timerslack_ns.
Bug: 372498744
Change-Id: Ib34cc6fbb4bab328cde51d60ac4e3b26a0d72851
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
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: I15c7763467cd9f65d4b389b2d4ccaff92012f21f
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: I0964d1300791334cdc9e98220324d934f7ba113e
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
