This reverts commit 52da71d47b.
Reason for revert: camera was using its own stale copy of libprocessgroup, and now has revved up its version that includes the new parsing code. So this time the json file update should work OK.
Original description:
To improve input latency, set the critical input threads to RT priority.
This will use RT priority on AOSP devices by default. OEMs can still
choose to customize what "input policy" means for their device, which
may not necessarily mean RT.
For example, on device with multiple small / big cores, input task
affinity could be changed to prioritize big cores + higher CPU frequency
/ voltage, but still keep the standard / default input thread priority.
Note: there is an open issue where the thread priority is not remaining constant. See b/378761104.
Bug: 330719044
Bug: 378761104
Flag: com.android.input.flags.enable_input_policy_profile
Test: took perfetto trace and checked the priority on InputDispatcher
and InputReader threads.
Change-Id: I449be0eeeac989222f5deefa62615478bd65b968
This reverts commit a2bd0e6b5d.
Reason for revert:DroidMonitor: Potential culprit for http://b/377739155 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I4c2b686aaf291db819d37711d4427d0094ca2295
This partially reverts commit de6707df0c.
Reason for revert: code change landed, now modifying JSON file only
Original description:
To improve input latency, set the critical input threads to RT priority.
This will use RT priority on AOSP devices by default. OEMs can still
choose to customize what "input policy" means for their device, which
may not necessarily mean RT.
For example, on device with multiple small / big cores, input task
affinity could be changed to prioritize big cores + higher CPU frequency
/ voltage, but still keep the standard / default input thread priority.
With this patch, I'm finding that sometimes, one of the critical input
threads has priority 100 instead of the expected 98. Still looking into
that specific issue, but the issue is already present with the existing
"input policy" code.
Bug: 330719044
Flag: com.android.input.flags.enable_input_policy_profile
Test: took perfetto trace and checked the priority on InputDispatcher
and InputReader threads.
Change-Id: I7d8a941f36ad9e4b75a7a0f4c5d81895256d6919
This reverts commit 930f77b02c.
Reason for revert: DroidMonitor: Potential culprit for http://b/376665573 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I9b9914703946f1eb4e40e779aa9cb5154ea108d3
To improve input latency, set the critical input threads to RT priority.
This will use RT priority on AOSP devices by default. OEMs can still
choose to customize what "input policy" means for their device, which
may not necessarily mean RT.
For example, on device with multiple small / big cores, input task
affinity could be changed to prioritize big cores + higher CPU frequency
/ voltage, but still keep the standard / default input thread priority.
With this patch, I'm finding that sometimes, one of the critical input
threads has priority 100 instead of the expected 98. Still looking into
that specific issue, but the issue is already present with the existing
"input policy" code.
Bug: 330719044
Flag: com.android.input.flags.enable_input_policy_profile
Test: took perfetto trace and checked the priority on InputDispatcher
and InputReader threads.
Change-Id: I75b6a726f0d066f16bdec26f6cf90721479d17ff
The SetClamps profile action has always been a no-op. Remove the class
and parsing code for this action.
Bug: 372915523
Change-Id: Ic6e685aa992b83464dfb5e6446b622a57ed61db5
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
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
Provide an additional way to request the block layer to prioritize
foreground I/O over background I/O. This patch prepares for tests with
the mq-deadline I/O scheduler. While CFQ and BFQ support a "weight"
cgroup attribute, the mq-deadline scheduler does not. The mq-deadline
I/O scheduler only supports the I/O priority class for differentiating
I/O priorities.
The io.prio.class attribute is declared optional since this attribute
only exists if CONFIG_BLK_CGROUP_IOPRIO != n in the kernel
configuration.
Bug: 186902601
Change-Id: Iee1004cd0996e32245aff2b51772ef40178e024f
Signed-off-by: Bart Van Assche <bvanassche@google.com>
There are multiple use cases in Android for which background writes need
to be controlled via the cgroup mechanism. The cgroup mechanism can only
control background writes if both the blkio and memcg controllers are
mounted in the v2 cgroup hierarchy. Hence this patch that migrates the
blkio controller from the v1 to the v2 cgroup hierarchy.
The changes compared to the previous version of this CL are as follows:
- The JoinCgroup actions for the "io" controller have been left out
since these caused processes to be migrated to the v2 root cgroup.
- The BfqWeight / CfqGroupIdle / CfqWeight settings have been included
in this CL instead of applying these settings as a separate CL.
Change-Id: I67e06ce3462bb1c1345dba78f8d3d655b6519c74
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit c7a6fe684c.
Repply the blkio controller migration because it was not responsible
for the test failures that led to the revert. See also the following bugs:
* https://b.corp.google.com/issues/260143932
(v2/android-virtual-infra/test_mapping/presubmit-avd test failure)
* https://b.corp.google.com/issues/264620181
(CtsInitTestCases.RebootTest#StopServicesSIGKILL failure)
The only change compared with the previous version is that the io
controller has been declared optional. This is necessary because some
devices have a kernel that does not support the io controller.
Bug: 213617178
Test: Cuttlefish and various phones
Change-Id: I490740e1c9ee4f7bb5bb7afba721a083f952c8f2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit 9c0fcbb0f7.
Bug: 261857030
Ignore-AOSP-First: this change is for the U branch only.
Change-Id: Id4bd3494b33dd6bc0644406d599c9bfd597c7435
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit 92153fb955.
Bug: 261857030
Ignore-AOSP-First: this change is for the U branch only.
Change-Id: I99417707f0d0b8c7dca3927b6ce9d52436621f4e
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit 6ad747ac2d.
Bug: 261857030
Ignore-AOSP-First: this change is for the U branch only.
Change-Id: I93447b71146e6e9297ef49026d90dc4c35b91244
Signed-off-by: Bart Van Assche <bvanassche@google.com>
There are multiple use cases in Android for which background writes need
to be controlled via the cgroup mechanism. The cgroup mechanism can only
control background writes if both the blkio and memcg controllers are
mounted in the v2 cgroup hierarchy. Hence this patch that migrates the
blkio controller from the v1 to the v2 cgroup hierarchy.
This patch increases the TOTAL_BOOT_TIME for devices with a 4.19 kernel
(redfin) from 18.9 s to 20 s. This patch does not affect the boot time
for devices with a 5.10 or 5.15 kernel.
This patch increases the time spent in CgroupMap::ActivateControllers()
by 25 microseconds in Cuttlefish on an x86-64 CPU.
CgroupMap::ActivateControllers() is called by Service::Start().
Bug: 213617178
Test: Cuttlefish and various phones
Change-Id: I490740e1c9ee4f7bb5bb7afba721a083f952c8f2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Adjusting attributes that correspond to the `blkio`(v1)/`io`(v2) controller. The migration of the `blkio` v1 controller to v2 requires renaming it to `io`, therefore we want to update the `File` field to point to `blkio` file and `FileV2` to point to `io` file.
Test: Verified with cuttlefish that this works with the `io` controller migration by cherry-picking aosp/2218645
Bug: 263269364
Bug: 213617178
Change-Id: I0aacfc6d74e3eec61ebb2ce443b04c792392aa9e
The differences between the v1 and v2 hierarchies are as follows:
* Different mountpoints. In Android the blkio v1 hierarchy has
/dev/blkio as top directory while the v2 hierarchy has /sys/fs/cgroup
as top directory.
* Different directory structure. In Android there are two directories in
the v1 blkio hierarchy (. and background) while in the v2 hierarchy
there is one subdirectory per process and per task.
* Different controller names. The name of the blkio controller in the v1
hierarchy is "blkio" while it is "io" in the v2 hierarchy.
* In the v1 hierarchy the NormalIoPriority policy is applied at process
creation time but that policy is not applied at process creation time
if the blkio controller exists in the v2 hierarchy.
Prepare for migration of the blkio controller to the v2 hierarchy by
adding the blkio v2 attributes in task_profiles.json. All these
attributes have been marked as optional because:
* The "io" controller does not exist in the v1 hierarchy.
* Which attributes can be applied depends on the I/O scheduler that has
been selected (CFQ, BFQ, ...).
This patch causes the following warnings to appear in the logs of
devices that mount the blkio controller in the v1 hierarchy:
W libprocessgroup: Controller io is not found
W libprocessgroup: Controller io is not found
W libprocessgroup: Controller io is not found
W libprocessgroup: SetAttribute: unknown attribute: CfqGroupIdle
W libprocessgroup: SetAttribute: unknown attribute: CfqWeight
W libprocessgroup: SetAttribute: unknown attribute: BfqWeight
This patch restores a subset of aosp/1962326 and prepares for the
migration of the blkcg controller to the cgroup v2 hierarchy.
Bug: 213617178
Change-Id: Ia7b117bc777239b416e2ac268308e634b018144d
Signed-off-by: Bart Van Assche <bvanassche@google.com>
There isn't any reason to keep the VMCompilationPerformance special, so
rename to a more generic, reusable name.
One day we may support whatever-purpose VMs using other generic
profiles.
Bug: 231437770
Test: TH
Change-Id: Id7e78ba4d6ea0dc415ed0bc1f4bdf051f7e7fe05
The VMCompilationPerformance profile is used to run Isolated Compilation
in a Protected VM, normally during the device idle, where relevant
APEXes are staged.
The original VMCompilationPerformance introduced in aosp/2060891 does
not have any specific definition and requires vendors to customize it.
This change re-defines it as an aggregated profile with a default set of
existing profiles, so that performance can be reasonable by default.
This profile may be renamed to a more generic name later, e.g.
"SCHED_SP_COMPUTE".
Bug: 231437770
Test: Run `composd_cmd test-compile` on a local device.
Before: 1m50s +/- 10s (with whatever that's default)
After: 1m25s +/- 5s
Change-Id: Ib8cd65782c818474fb129efbd9ef9a3e23ad1eb3
Revert "Migrate the blkio controller to the cgroup v2 hierarchy"
Revert "Migrate the blkio controller to the cgroup v2 hierarchy"
Revert "Migrate the blkio controller to the cgroup v2 hierarchy"
Revert submission 1962326-blkio-cgroup-v2
Reason for revert: This set of changes is suspected to have caused a redfin boot time regression for the git_tm-dev branch.
Reverted Changes:
Id18d876b6:Migrate the blkio controller to the cgroup v2 hier...
I7dfa52136:Migrate the blkio controller to the v2 cgroup hier...
I5336167be:Migrate the blkio controller to the cgroup v2 hier...
I3f0131d8f:Migrate the blkio controller to the cgroup v2 hier...
Ibb62b2d4d:Migrate the blkio controller to the cgroup v2 hier...
Bug: 227382327
Bug: 227389363
Change-Id: I6c8183ed1c3044c8947c4fca07799deff98101b3
This patch preserves the following parameter values:
* Foreground BFQ weight: 100
* Foreground CFQ group_idle: 0
* Foreground CFQ weight: 1000
* Background BFQ weight: 10
* Background CFQ group_idle: 0
* Background CFQ weight: 200
The foreground BFQ weight in task_profiles.json is the default BFQ
weight. From
https://www.kernel.org/doc/Documentation/block/bfq-iosched.txt:
"weight (namely blkio.bfq.weight or io.bfq-weight): the weight of the
group inside its parent. Available values: 1..10000 (default 100). The
linear mapping between ioprio and weights, described at the beginning
of the tunable section, is still valid, but all weights higher than
IOPRIO_BE_NR*10 are mapped to ioprio 0."
Bug: 213617178
Test: Booted Android in Cuttlefish and ran the following test:
Test: adb -e shell cat /sys/fs/cgroup/*/*/io.bfq.weight | sort | uniq -c
Test: 22 default 10
Test: 98 default 100
Change-Id: I7dfa521363a316592852fecce9192708c7a90514
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Some but not all memcg v1 attributes exist in the v2 hierarchy. The
following information comes from Shakeel Butt and Kamil Yurtsever,
"cgroup v2 migration at Google", Linux Plumbers Conference 2018
( https://lpc.events/event/2/contributions/204/attachments/143/378/LPC2018-cgroup-v2.pdf ):
v1 v2
-------------------------- ----------
memory.limit_in_bytes memory.max
memory.soft_limit_in_bytes memory.low
Add support for cgroup attributes that have different names in the v1
and v2 hierarchies. Also add those memcg attributes that are used in
lmkd.
Bug: 213617178
Test: Tested lmkd with v1 and v2 memcg.
Change-Id: Ia5c5f02974f3b783d5cdaad85b33169ced8db55f
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Cgroup attributes like io.weight or io.bfq.weight only exist if the
corresponding I/O scheduler has been loaded. Hence add support for
ignoring failures to write to a cgroup attribute that does not exist.
Bug: 213617178
Test: This patch has been tested in combination with patch "Migrate the blkio controller to the cgroup v2 hierarchy".
Change-Id: I5debafabc4dd430a1b98ea343bf3740c764edcc3
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Cgroup attributes are set from three different contexts:
(1) From the process that creates the cgroup directories. These
processes are /system/bin/init, zygote and zygote64.
(2) From the created process. Some but not all created processes have
user ID and/or group ID 'system'.
(3) The system_server process modifies certain cgroup attributes from
other processes.
Allow all processes from the system group, including system_server, to
modify cgroup attributes from other processes. As one can see in
init.rc, that file includes commands for granting the system group
write permission for blkcg attributes. See also
https://cs.android.com/android/platform/superproject/+/master:system/core/rootdir/init.rc
Bug: 213617178
Test: Verified in the Cuttlefish emulator that this patch makes the
Test: io.bfq.weight write errors disappear from logcat.
Change-Id: Idbfb49c25afec12b21daea7a17db5322bc981ff0
Signed-off-by: Bart Van Assche <bvanassche@google.com>
cgroups.json causes the following changes to be applied twice to
/sys/fs/cgroup: change user ID to system, change group ID to system and
change mode to 0755. Apply these settings once instead of twice.
Bug: 213617178
Test: Ran ls -ld /sys/fs/cgroup in Cuttlefish.
Change-Id: Ieb953c186c027b989599cbbaa70a9c9324678cdf
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Create a new group for dex2oat in cpu cgroup, which is dedicated for
dex2oat processes. Also modify task profiles for this change.
Bug: 201223712
Test: dex2oat group created
Change-Id: Ic61f4b8a64d01c03549b680970805e12b9ce4fcc
Since we are adding SCHED_SP_SYSTEM into framework, the policy is needed
on older releases as well.
Bug: 201428466
Test: Build
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I0784820bfec84fd8ef98f2feb2caee084d0a14a2
Since installation time is also critical and sometime we want a finer
control on its behavior for vendor. Instead of set dex2oat to background
group, add a new task profile.
The default policy is to mirror SP_BACKGROUND to be compatible with
legacy devices.
Test: Boot
Bug: 188947181
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I7d5e113d1c368205f712eadad27775de226131ce
(cherry picked from commit 3745ce7aa8)
In some platforms, setting a different cpuset (or remove it) and/or
uclamp setting is beneficial to both performance and power. Adding 2
separate profiles for vendor to override surfaceflinger scheduling
policies.
Bug: 170507315
Test: build and boot
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: Ib313fd67c6ccd701109c5683d8dbab9ecd1580d8
(cherry picked from commit 6d6b71e582)
Memory cgroup controller is not used by high-end Android devices and is
disabled in Android kernels 5.10+, however Android Go devices still
require this controller.
Similarly schedtune controller is being replaced with cpu controller's
utilclamp feature, however some devices are using older kernels which
only support schedtune.
To prevent spamming logcat with errors we need a way to mark a
controller optional in such cases without removing it from
cgroups.json file.
Introduce "Optional" attribute to cgroup controller's cgroups.json
description to accomodate these cases. When an optional controller
fails to mount due to lack of support in the kernel it will log an
informational message without generating further errors.
Bug: 181866655
Test: boot and observe libprocessgroup messages in logcat
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ib5bcfdd8d338704f3f9d8b326d8ddd88b67915a1
