These macros have been useless in this file since commit 82b72a566
("libprocessgroup: Add support for task profiles") in 2018 which added
C++ includes, and C++ types and keywords inside an extern "C" block.
Change-Id: Iae1cbfcc5cb974034d88fb466b79088496190940
Almost everywhere CGROUPV2_HIERARCHY_NAME is used a std::string is
required, so change its type to avoid temporaries.
Change-Id: I4466838c510f2eb8212fc71999cdaa47359ce9c3
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 de6707df0c.
Reason for revert: changing code without modifying JSON file now
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: I3dabf4da0398324cf542e701c103551343b883cf
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
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
