From: Kajetan Puchalski <kajetan.puchalski@arm.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: daniel.lezcano@linaro.org, lukasz.luba@arm.com,
Dietmar.Eggemann@arm.com, dsmythies@telus.net,
yu.chen.surf@gmail.com, kajetan.puchalski@arm.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/1] cpuidle: teo: Introduce optional util-awareness
Date: Thu, 20 Oct 2022 17:20:45 +0100 [thread overview]
Message-ID: <Y1F0GYlJJOnFQeYe@e126311.manchester.arm.com> (raw)
In-Reply-To: <CAJZ5v0hoe=8nY9vR=+Bjvexrg+E6fcO-S=W+PDkfD=Li6Uy__g@mail.gmail.com>
Hi Rafael,
> The avg_util value tells us nothing about how much the CPU is going to
> be idle this time and it also tells us nothing about the
> latency-sensitivity of the workload.
>
> Yes, it tells us how much idle time there was on the given CPU in the
> past, on the average, but there is zero information about the
> distribution of that idle time in it.
>
> So in the first place please tell me why it fundamentally makes sense
> to use avg_util in CPU idle time management at all.
I have an alternative suggestion that could be a reasonable way forward
here. Instead of applying util-awareness on top of TEO where it would
have to be reconciled with how TEO is currently expected to work, I just
wrote a simple completely new governor which operates only on timer
events alongside util values.
The idea is this:
1. Find the deepest state based on residency and time until the next timer event
2. If sched_cpu_util() is above the threshold, select a shallower non-polling state
There's no other metrics or anything else under the current
implementation. I can't say how it would work on Intel systems and in
the presence of more idle states but having a completely separate
governor would be very useful for us to tune it specifically for our use
cases and types of systems (ie. ones with 2 idle states and no polling
states).
As it stands it performs quite well and achieves better results
(especially in terms of latency) than both menu & TEO but slightly worse
than the previously suggested TEO + util. As far as we're concerned
that's okay, we can work from there to try to find a way of doing
metrics or improving the algorithm that would be more tailored to using
the util approach. I think it's much cleaner than what we were
discussing previously since that was effectively overriding most of what
TEO was doing.
Here are some numbers to visualize the results. They were all obtained
in the same way as the ones in the cover letter so you can refer to that
in case something isn't clear.
'teo_util' is of course TEO + util as in the patchset.
'idleutil' is this entirely new proposed minimal governor.
1. Geekbench 5 (latency-sensitive, heavy load test)
+-----------------+----------+---------+-------------+
| metric | kernel | value | perc_diff |
|-----------------+----------+---------+-------------|
| multicore_score | menu | 2832.3 | 0.0% |
| multicore_score | teo | 2815.3 | -0.6% |
| multicore_score | teo_util | 2880.6 | 1.7% |
| multicore_score | idleutil | 2859.3 | 0.95% |
+-----------------+----------+---------+-------------+
Percentages & types of idle misses
+-----------+-------------+--------------+
| kernel | type | percentage |
|-----------+-------------+--------------|
| menu | too deep | 15.613% |
| teo | too deep | 9.376% |
| teo_util | too deep | 4.581% |
| idleutil | too deep | 5.464% |
| menu | too shallow | 2.611% |
| teo | too shallow | 6.099% |
| teo_util | too shallow | 14.141% |
| idleutil | too shallow | 13.282% |
+-----------+-------------+--------------+
Power usage [mW]
+--------------+----------+----------+---------+-------------+
| chan_name | metric | kernel | value | perc_diff |
|--------------+----------+----------+---------+-------------|
| total_power | gmean | menu | 2705.9 | 0.0% |
| total_power | gmean | teo | 2668.2 | -1.39% |
| total_power | gmean | teo_util | 2710.2 | 0.16% |
| total_power | gmean | idleutil | 2657.9 | -1.78% |
+--------------+----------+----------+---------+-------------+
Wakeup latency
+-----------------+----------+----------+-------------+-------------+
| comm | metric | kernel | value | perc_diff |
|-----------------+----------+----------+-------------+-------------|
| AsyncTask #1 | gmean | menu | 66.85μs | 0.0% |
| AsyncTask #1 | gmean | teo | 66.79μs | -0.09% |
| AsyncTask #1 | gmean | teo_util | 57.84μs | -13.47% |
| AsyncTask #1 | gmean | idleutil | 62.61μs | -6.35% |
| labs.geekbench5 | gmean | menu | 80.62μs | 0.0% |
| labs.geekbench5 | gmean | teo | 94.75μs | 17.52% |
| labs.geekbench5 | gmean | teo_util | 52.98μs | -34.28% |
| labs.geekbench5 | gmean | idleutil | 68.58μs | -14.93% |
+-----------------+----------+----------+-------------+-------------+
2. PCMark Web Browsing (non latency-sensitive, normal usage test)
+----------------+----------+---------+-------------+
| metric | kernel | value | perc_diff |
|----------------+----------+---------+-------------|
| PcmaWebV2Score | menu | 5232 | 0.0% |
| PcmaWebV2Score | teo | 5219.8 | -0.23% |
| PcmaWebV2Score | teo_util | 5249.7 | 0.34% |
| PcmaWebV2Score | idleutil | 5215.7 | -0.31% |
+----------------+----------+---------+-------------+
Percentages & types of idle misses
+-----------+-------------+--------------+
| kernel | type | percentage |
|-----------+-------------+--------------|
| menu | too deep | 24.814% |
| teo | too deep | 11.65% |
| teo_util | too deep | 3.753% |
| idleutil | too deep | 4.304% |
| menu | too shallow | 3.101% |
| teo | too shallow | 8.578% |
| teo_util | too shallow | 18.309% |
| idleutil | too shallow | 17.638% |
+-----------+-------------+--------------+
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 | 180.5 | 0.71% |
| total_power | gmean | idleutil | 185 | 3.24% |
+--------------+----------+----------+---------+-------------+
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 | 111.76μs | -52.77% |
| CrRendererMain | gmean | idleutil | 105.55μs | -55.39% |
| chmark:workload | gmean | menu | 100.30μs | 0.0% |
| chmark:workload | gmean | teo | 80.20μs | -20.04% |
| chmark:workload | gmean | teo_util | 53.81μs | -46.35% |
| chmark:workload | gmean | idleutil | 71.29μs | -28.92% |
| RenderThread | gmean | menu | 37.97μs | 0.0% |
| RenderThread | gmean | teo | 31.69μs | -16.54% |
| RenderThread | gmean | teo_util | 34.32μs | -9.63% |
| RenderThread | gmean | idleutil | 35.78μs | -5.77% |
| surfaceflinger | gmean | menu | 97.57μs | 0.0% |
| surfaceflinger | gmean | teo | 98.86μs | 1.31% |
| surfaceflinger | gmean | teo_util | 72.59μs | -25.6% |
| surfaceflinger | gmean | idleutil | 56.23μs | -42.37% |
+-----------------+----------+----------+-------------+-------------+
I also have similar data for Jankbench & Speedometer with right about
the same results, I'll skip those for now for brevity.
Would you like me to send a patch with this new governor instead? What
would you think about this instead of the previously suggested approach?
Thanks,
Kajetan
next prev parent reply other threads:[~2022-10-20 16:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-03 14:49 [RFC PATCH v2 0/1] cpuidle: teo: Introduce optional util-awareness Kajetan Puchalski
2022-10-03 14:49 ` [RFC PATCH v2 1/1] " Kajetan Puchalski
2022-10-07 0:06 ` [RFC PATCH v2 0/1] " Doug Smythies
2022-10-10 10:09 ` Kajetan Puchalski
2022-10-11 8:21 ` Lukasz Luba
2022-10-12 18:50 ` Rafael J. Wysocki
2022-10-13 11:12 ` Kajetan Puchalski
2022-10-13 22:12 ` Doug Smythies
2022-10-27 19:56 ` Lukasz Luba
2022-10-28 13:29 ` Rafael J. Wysocki
2022-10-27 20:04 ` Lukasz Luba
2022-10-28 13:37 ` Rafael J. Wysocki
2022-10-28 13:12 ` Rafael J. Wysocki
2022-10-28 15:00 ` Kajetan Puchalski
2022-10-28 15:04 ` Rafael J. Wysocki
2022-10-28 15:08 ` Rafael J. Wysocki
2022-10-20 16:20 ` Kajetan Puchalski [this message]
2022-10-20 19:52 ` Daniel Lezcano
2022-10-28 7:08 ` Lukasz Luba
2022-10-28 7:11 ` Daniel Lezcano
2022-10-28 7:23 ` Lukasz Luba
2022-10-28 13:25 ` Rafael J. Wysocki
2022-10-28 13:22 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1F0GYlJJOnFQeYe@e126311.manchester.arm.com \
--to=kajetan.puchalski@arm.com \
--cc=Dietmar.Eggemann@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rafael@kernel.org \
--cc=yu.chen.surf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox