lkml.org 
[lkml]   [2023]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 0/2] cpuidle: teo: Introduce util-awareness
On Thu, Jan 12, 2023 at 08:22:24PM +0100, Rafael J. Wysocki wrote:
> On Thu, Jan 5, 2023 at 3:52 PM Kajetan Puchalski
> <kajetan.puchalski@arm.com> wrote:
> >
> > Hi,
> >
> > At the moment, none of the available idle governors take any scheduling
> > information into account. They also tend to overestimate the idle
> > duration quite often, which causes them to select excessively deep idle
> > states, thus leading to increased wakeup latency and lower performance with no
> > power saving. For 'menu' while web browsing on Android for instance, those
> > types of wakeups ('too deep') account for over 24% of all wakeups.
> >
> > At the same time, on some platforms idle state 0 can be power efficient
> > enough to warrant wanting to prefer it over idle state 1. This is because
> > the power usage of the two states can be so close that sufficient amounts
> > of too deep state 1 sleeps can completely offset the state 1 power saving to the
> > point where it would've been more power efficient to just use state 0 instead.
> > This is of course for systems where state 0 is not a polling state, such as
> > arm-based devices.
> >
> > Sleeps that happened in state 0 while they could have used state 1 ('too shallow') only
> > save less power than they otherwise could have. Too deep sleeps, on the other
> > hand, harm performance and nullify the potential power saving from using state 1 in
> > the first place. While taking this into account, it is clear that on balance it
> > is preferable for an idle governor to have more too shallow sleeps instead of
> > more too deep sleeps on those kinds of platforms.
> >
> > Currently the best available governor under this metric is TEO which on average results in less than
> > half the percentage of too deep sleeps compared to 'menu', getting much better wakeup latencies and
> > increased performance in the process.
> >
> > This patchset specifically tunes TEO to prefer shallower idle states in order to reduce wakeup latency
> > and achieve better performance. To this end, before selecting the next idle state it uses the avg_util
> > signal of a CPU's runqueue in order to determine to what extent the CPU is being utilized.
> > This util value is then compared to a threshold defined as a percentage of the cpu's capacity
> > (capacity >> 6 ie. ~1.5% in the current implementation). If the util is above the threshold, the idle
> > state selected by TEO metrics will be reduced by 1, thus selecting a shallower state. If the util is
> > below the threshold, the governor defaults to the TEO metrics mechanism to try to select the deepest
> > available idle state based on the closest timer event and its own correctness.
> >
> > The main goal of this is to reduce latency and increase performance for some workloads. Under some
> > workloads it will result in an increase in power usage (Geekbench 5) while for other workloads it
> > will also result in a decrease in power usage compared to TEO (PCMark Web, Jankbench, Speedometer).
> >
> > As of v2 the patch includes a 'fast exit' path for arm-based and similar systems where only 2 idle
> > states are present. If there's just 2 idle states and the CPU is utilized, we can directly select
> > the shallowest state and save cycles by skipping the entire metrics mechanism.
> >
> > Under the current implementation, the state will not be reduced by 1 if the change would lead to
> > selecting a polling state instead of a non-polling state.
> >
> > This approach can outperform all the other currently available governors, at least on mobile device
> > workloads, which is why I think it is worth keeping as an option.
> >
> > There is no particular attachment or reliance on TEO for this mechanism, I simply chose to base
> > it on TEO because it performs the best out of all the available options and I didn't think there was
> > any point in reinventing the wheel on the side of computing governor metrics. If a
> > better approach comes along at some point, there's no reason why the same idle aware mechanism
> > couldn't be used with any other metrics algorithm. That would, however, require implemeting it as
> > a separate governor rather than a TEO add-on.
> >
> > As for how the extension performs in practice, below I'll add some benchmark results I got while
> > testing this patchset. All the benchmarks were run after holding the phone in the fridge for exactly
> > an hour each time to minimise the impact of thermal issues.
> >
> > Pixel 6 (Android 12, mainline kernel 5.18, with newer mainline CFS patches):
> >
> > 1. Geekbench 5 (latency-sensitive, heavy load test)
> >
> > The values below are gmean values across 3 back to back iteration of Geekbench 5.
> > As GB5 is a heavy benchmark, after more than 3 iterations intense throttling kicks in on mobile devices
> > resulting in skewed benchmark scores, which makes it difficult to collect reliable results. The actual
> > values for all of the governors can change between runs as the benchmark might be affected by factors
> > other than just latency. Nevertheless, on the runs I've seen, util-aware TEO frequently achieved better
> > scores than all the other governors.
> >
> > Benchmark scores
> >
> > +-----------------+-------------+---------+-------------+
> > | metric | kernel | value | perc_diff |
> > |-----------------+-------------+---------+-------------|
> > | multicore_score | menu | 2826.5 | 0.0% |
> > | multicore_score | teo | 2764.8 | -2.18% |
> > | multicore_score | teo_util_v3 | 2849 | 0.8% |
> > | multicore_score | teo_util_v4 | 2865 | 1.36% |
> > | score | menu | 1053 | 0.0% |
> > | score | teo | 1050.7 | -0.22% |
> > | score | teo_util_v3 | 1059.6 | 0.63% |
> > | score | teo_util_v4 | 1057.6 | 0.44% |
> > +-----------------+-------------+---------+-------------+
> >
> > Idle misses
> >
> > The numbers are percentages of too deep and too shallow sleeps computed using the new trace
> > event - cpu_idle_miss. The percentage is obtained by counting the two types of misses over
> > the course of a run and then dividing them by the total number of wakeups in that run.
> >
> > +-------------+-------------+--------------+
> > | wa_path | type | count_perc |
> > |-------------+-------------+--------------|
> > | menu | too deep | 14.994% |
> > | teo | too deep | 9.649% |
> > | teo_util_v3 | too deep | 4.298% |
> > | teo_util_v4 | too deep | 4.02 % |
> > | menu | too shallow | 2.497% |
> > | teo | too shallow | 5.963% |
> > | teo_util_v3 | too shallow | 13.773% |
> > | teo_util_v4 | too shallow | 14.598% |
> > +-------------+-------------+--------------+
> >
> > Power usage [mW]
> >
> > +--------------+----------+-------------+---------+-------------+
> > | chan_name | metric | kernel | value | perc_diff |
> > |--------------+----------+-------------+---------+-------------|
> > | total_power | gmean | menu | 2551.4 | 0.0% |
> > | total_power | gmean | teo | 2606.8 | 2.17% |
> > | total_power | gmean | teo_util_v3 | 2670.1 | 4.65% |
> > | total_power | gmean | teo_util_v4 | 2722.3 | 6.7% |
> > +--------------+----------+-------------+---------+-------------+
> >
> > Task wakeup latency
> >
> > +-----------------+----------+-------------+-------------+-------------+
> > | comm | metric | kernel | value | perc_diff |
> > |-----------------+----------+-------------+-------------+-------------|
> > | AsyncTask #1 | gmean | menu | 78.16μs | 0.0% |
> > | AsyncTask #1 | gmean | teo | 61.60μs | -21.19% |
> > | AsyncTask #1 | gmean | teo_util_v3 | 74.34μs | -4.89% |
> > | AsyncTask #1 | gmean | teo_util_v4 | 54.45μs | -30.34% |
> > | labs.geekbench5 | gmean | menu | 88.55μs | 0.0% |
> > | labs.geekbench5 | gmean | teo | 100.97μs | 14.02% |
> > | labs.geekbench5 | gmean | teo_util_v3 | 53.57μs | -39.5% |
> > | labs.geekbench5 | gmean | teo_util_v4 | 59.60μs | -32.7% |
> > +-----------------+----------+-------------+-------------+-------------+
> >
> > In case of this benchmark, the difference in latency does seem to translate into better scores.
> >
> > 2. PCMark Web Browsing (non latency-sensitive, normal usage web browsing test)
> >
> > The table below contains gmean values across 20 back to back iterations of PCMark 2 Web Browsing.
> >
> > Benchmark scores
> >
> > +----------------+-------------+---------+-------------+
> > | metric | kernel | value | perc_diff |
> > |----------------+-------------+---------+-------------|
> > | PcmaWebV2Score | menu | 5232 | 0.0% |
> > | PcmaWebV2Score | teo | 5219.8 | -0.23% |
> > | PcmaWebV2Score | teo_util_v3 | 5273.5 | 0.79% |
> > | PcmaWebV2Score | teo_util_v4 | 5239.9 | 0.15% |
> > +----------------+-------------+---------+-------------+
> >
> > Idle misses
> >
> > +-------------+-------------+--------------+
> > | wa_path | type | count_perc |
> > |-------------+-------------+--------------|
> > | menu | too deep | 24.814% |
> > | teo | too deep | 11.65% |
> > | teo_util_v3 | too deep | 3.481% |
> > | teo_util_v4 | too deep | 3.662% |
> > | menu | too shallow | 3.101% |
> > | teo | too shallow | 8.578% |
> > | teo_util_v3 | too shallow | 18.326% |
> > | teo_util_v4 | too shallow | 18.692% |
> > +-------------+-------------+--------------+
> >
> > Power usage [mW]
> >
> > +--------------+----------+-------------+---------+-------------+
> > | chan_name | metric | kernel | value | perc_diff |
> > |--------------+----------+-------------+---------+-------------|
> > | total_power | gmean | menu | 179.2 | 0.0% |
> > | total_power | gmean | teo | 184.8 | 3.1% |
> > | total_power | gmean | teo_util_v3 | 177.4 | -1.02% |
> > | total_power | gmean | teo_util_v4 | 184.1 | 2.71% |
> > +--------------+----------+-------------+---------+-------------+
> >
> > Task wakeup latency
> >
> > +-----------------+----------+-------------+-------------+-------------+
> > | comm | metric | kernel | value | perc_diff |
> > |-----------------+----------+-------------+-------------+-------------|
> > | CrRendererMain | gmean | menu | 236.63μs | 0.0% |
> > | CrRendererMain | gmean | teo | 201.85μs | -14.7% |
> > | CrRendererMain | gmean | teo_util_v3 | 106.46μs | -55.01% |
> > | CrRendererMain | gmean | teo_util_v4 | 106.72μs | -54.9% |
> > | chmark:workload | gmean | menu | 100.30μs | 0.0% |
> > | chmark:workload | gmean | teo | 80.20μs | -20.04% |
> > | chmark:workload | gmean | teo_util_v3 | 65.88μs | -34.32% |
> > | chmark:workload | gmean | teo_util_v4 | 57.90μs | -42.28% |
> > | surfaceflinger | gmean | menu | 97.57μs | 0.0% |
> > | surfaceflinger | gmean | teo | 98.86μs | 1.31% |
> > | surfaceflinger | gmean | teo_util_v3 | 56.49μs | -42.1% |
> > | surfaceflinger | gmean | teo_util_v4 | 72.68μs | -25.52% |
> > +-----------------+----------+-------------+-------------+-------------+
> >
> > In this case the large latency improvement does not translate into a notable increase in benchmark score as
> > this particular benchmark mainly responds to changes in operating frequency.
> >
> > 3. Jankbench (locked 60hz screen) (normal usage UI test)
> >
> > Frame durations
> >
> > +---------------+------------------+---------+-------------+
> > | variable | kernel | value | perc_diff |
> > |---------------+------------------+---------+-------------|
> > | mean_duration | menu_60hz | 13.9 | 0.0% |
> > | mean_duration | teo_60hz | 14.7 | 6.0% |
> > | mean_duration | teo_util_v3_60hz | 13.8 | -0.87% |
> > | mean_duration | teo_util_v4_60hz | 12.6 | -9.0% |
> > +---------------+------------------+---------+-------------+
> >
> > Jank percentage
> >
> > +------------+------------------+---------+-------------+
> > | variable | kernel | value | perc_diff |
> > |------------+------------------+---------+-------------|
> > | jank_perc | menu_60hz | 1.5 | 0.0% |
> > | jank_perc | teo_60hz | 2.1 | 36.99% |
> > | jank_perc | teo_util_v3_60hz | 1.3 | -13.95% |
> > | jank_perc | teo_util_v4_60hz | 1.3 | -17.37% |
> > +------------+------------------+---------+-------------+
> >
> > Idle misses
> >
> > +------------------+-------------+--------------+
> > | wa_path | type | count_perc |
> > |------------------+-------------+--------------|
> > | menu_60hz | too deep | 26.00% |
> > | teo_60hz | too deep | 11.00% |
> > | teo_util_v3_60hz | too deep | 2.33% |
> > | teo_util_v4_60hz | too deep | 2.54% |
> > | menu_60hz | too shallow | 4.74% |
> > | teo_60hz | too shallow | 11.89% |
> > | teo_util_v3_60hz | too shallow | 21.78% |
> > | teo_util_v4_60hz | too shallow | 21.93% |
> > +------------------+-------------+--------------+
> >
> > Power usage [mW]
> >
> > +--------------+------------------+---------+-------------+
> > | chan_name | kernel | value | perc_diff |
> > |--------------+------------------+---------+-------------|
> > | total_power | menu_60hz | 144.6 | 0.0% |
> > | total_power | teo_60hz | 136.9 | -5.27% |
> > | total_power | teo_util_v3_60hz | 134.2 | -7.19% |
> > | total_power | teo_util_v4_60hz | 121.3 | -16.08% |
> > +--------------+------------------+---------+-------------+
> >
> > Task wakeup latency
> >
> > +-----------------+------------------+-------------+-------------+
> > | comm | kernel | value | perc_diff |
> > |-----------------+------------------+-------------+-------------|
> > | RenderThread | menu_60hz | 139.52μs | 0.0% |
> > | RenderThread | teo_60hz | 116.51μs | -16.49% |
> > | RenderThread | teo_util_v3_60hz | 86.76μs | -37.82% |
> > | RenderThread | teo_util_v4_60hz | 91.11μs | -34.7% |
> > | droid.benchmark | menu_60hz | 135.88μs | 0.0% |
> > | droid.benchmark | teo_60hz | 105.21μs | -22.57% |
> > | droid.benchmark | teo_util_v3_60hz | 83.92μs | -38.24% |
> > | droid.benchmark | teo_util_v4_60hz | 83.18μs | -38.79% |
> > | surfaceflinger | menu_60hz | 124.03μs | 0.0% |
> > | surfaceflinger | teo_60hz | 151.90μs | 22.47% |
> > | surfaceflinger | teo_util_v3_60hz | 100.19μs | -19.22% |
> > | surfaceflinger | teo_util_v4_60hz | 87.65μs | -29.33% |
> > +-----------------+------------------+-------------+-------------+
> >
> > 4. Speedometer 2 (heavy load web browsing test)
> >
> > Benchmark scores
> >
> > +-------------------+-------------+---------+-------------+
> > | metric | kernel | value | perc_diff |
> > |-------------------+-------------+---------+-------------|
> > | Speedometer Score | menu | 102 | 0.0% |
> > | Speedometer Score | teo | 104.9 | 2.88% |
> > | Speedometer Score | teo_util_v3 | 102.1 | 0.16% |
> > | Speedometer Score | teo_util_v4 | 103.8 | 1.83% |
> > +-------------------+-------------+---------+-------------+
> >
> > Idle misses
> >
> > +-------------+-------------+--------------+
> > | wa_path | type | count_perc |
> > |-------------+-------------+--------------|
> > | menu | too deep | 17.95% |
> > | teo | too deep | 6.46% |
> > | teo_util_v3 | too deep | 0.63% |
> > | teo_util_v4 | too deep | 0.64% |
> > | menu | too shallow | 3.86% |
> > | teo | too shallow | 8.21% |
> > | teo_util_v3 | too shallow | 14.72% |
> > | teo_util_v4 | too shallow | 14.43% |
> > +-------------+-------------+--------------+
> >
> > Power usage [mW]
> >
> > +--------------+----------+-------------+---------+-------------+
> > | chan_name | metric | kernel | value | perc_diff |
> > |--------------+----------+-------------+---------+-------------|
> > | total_power | gmean | menu | 2059 | 0.0% |
> > | total_power | gmean | teo | 2187.8 | 6.26% |
> > | total_power | gmean | teo_util_v3 | 2212.9 | 7.47% |
> > | total_power | gmean | teo_util_v4 | 2121.8 | 3.05% |
> > +--------------+----------+-------------+---------+-------------+
> >
> > Task wakeup latency
> >
> > +-----------------+----------+-------------+-------------+-------------+
> > | comm | metric | kernel | value | perc_diff |
> > |-----------------+----------+-------------+-------------+-------------|
> > | CrRendererMain | gmean | menu | 17.18μs | 0.0% |
> > | CrRendererMain | gmean | teo | 16.18μs | -5.82% |
> > | CrRendererMain | gmean | teo_util_v3 | 18.04μs | 5.05% |
> > | CrRendererMain | gmean | teo_util_v4 | 18.25μs | 6.27% |
> > | RenderThread | gmean | menu | 68.60μs | 0.0% |
> > | RenderThread | gmean | teo | 48.44μs | -29.39% |
> > | RenderThread | gmean | teo_util_v3 | 48.01μs | -30.02% |
> > | RenderThread | gmean | teo_util_v4 | 51.24μs | -25.3% |
> > | surfaceflinger | gmean | menu | 42.23μs | 0.0% |
> > | surfaceflinger | gmean | teo | 29.84μs | -29.33% |
> > | surfaceflinger | gmean | teo_util_v3 | 24.51μs | -41.95% |
> > | surfaceflinger | gmean | teo_util_v4 | 29.64μs | -29.8% |
> > +-----------------+----------+-------------+-------------+-------------+
> >
> > Thank you for taking your time to read this!
> >
> > --
> > Kajetan
> >
> > v5 -> v6:
> > - amended some wording in the commit description & cover letter
> > - included test results in the commit description
> > - refactored checking the CPU utilized status to account for !SMP systems
> > - dropped the RFC from the patchset header
> >
> > v4 -> v5:
> > - remove the restriction to only apply the mechanism for C1 candidate state
> > - clarify some code comments, fix comment style
> > - refactor the fast-exit path loop implementation
> > - move some cover letter information into the commit description
> >
> > v3 -> v4:
> > - remove the chunk of code skipping metrics updates when the CPU was utilized
> > - include new test results and more benchmarks in the cover letter
> >
> > v2 -> v3:
> > - add a patch adding an option to skip polling states in teo_find_shallower_state()
> > - only reduce the state if the candidate state is C1 and C0 is not a polling state
> > - add a check for polling states in the 2-states fast-exit path
> > - remove the ifdefs and Kconfig option
> >
> > v1 -> v2:
> > - rework the mechanism to reduce selected state by 1 instead of directly selecting C0 (suggested by Doug Smythies)
> > - add a fast-exit path for systems with 2 idle states to not waste cycles on metrics when utilized
> > - fix typos in comments
> > - include a missing header
> >
> >
> > Kajetan Puchalski (2):
> > cpuidle: teo: Optionally skip polling states in teo_find_shallower_state()
> > cpuidle: teo: Introduce util-awareness
> >
> > drivers/cpuidle/governors/teo.c | 100 ++++++++++++++++++++++++++++++--
> > 1 file changed, 96 insertions(+), 4 deletions(-)
> >
> > --
>
> Both patches in the series applied as 6.3 material, thanks!

Thanks a lot, take care!

\
 
 \ /
  Last update: 2023-03-26 23:39    [W:0.158 / U:1.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site