diff options
| author | 2024-06-28 14:29:48 +0000 | |
|---|---|---|
| committer | 2024-06-28 17:22:06 +0000 | |
| commit | 36a6e82709b2d3793877f549d0bd4dd75bfb2e2a (patch) | |
| tree | 70fa9a59ee714806a9003c6b4f843f1ffd74c7df /compiler/optimizing/code_generator.h | |
| parent | 1d9301bc2ec7a060ba8e8a8a0106feff4a094927 (diff) | |
Set default concurrency for post-boot reasons to 1.
A field trace shows that the background dexopt job is running when
device screen is on. This is not expected. Before finding out why the
job scheduler doesn't cancel the job when device screen is on, setting
concurrency to 1 mitigates the user-perceptible impact. Note that this
is not a proper fix for this issue.
In addition, some other field traces show that, even if the device is
idle, there are still a lot things going on. For example, a store may
be updating apps in the background, and some apps may be syncing data
to the cloud. A high dexopt concurrency adds CPU pressure and memory
pressure, causing LMKs or timeouts on dexopt itself as well as other
things. Setting concurrency to 1 mitigates this problem.
Field data showed that, compared to concurrency 1, concurrency 4 reduces
the average background dexopt job duration by 2.8 mins, from 8.04 to
5.24 mins (34.8% improvement). However, at the moment, the drawbacks
outweigh the benefits. We may revisit this when problems above are
addressed.
This change also removes the wrong P/H flag read.
Bug: 349108670
Bug: 346663133
Change-Id: Id58d9b45532270e277ad59cbf47ef90e5daf9f83
Diffstat (limited to 'compiler/optimizing/code_generator.h')
0 files changed, 0 insertions, 0 deletions