From: Quentin Perret <qperret@google.com>
To: Vincent Donnefort <vincent.donnefort@arm.com>
Cc: peterz@infradead.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
vincent.guittot@linaro.org, linux-kernel@vger.kernel.org,
ionela.voinescu@arm.com, lukasz.luba@arm.com,
dietmar.eggemann@arm.com
Subject: Re: [PATCH] PM / EM: Inefficient OPPs detection
Date: Fri, 23 Apr 2021 16:14:44 +0000 [thread overview]
Message-ID: <YILydL1QDxvuiFde@google.com> (raw)
In-Reply-To: <20210422153644.GA316798@e124901.cambridge.arm.com>
On Thursday 22 Apr 2021 at 16:36:44 (+0100), Vincent Donnefort wrote:
> > > As used in the hot-path, the efficient table is a lookup table, generated
> > > dynamically when the perf domain is created. The complexity of searching
> > > a performance state is hence changed from O(n) to O(1). This also
> > > speeds-up em_cpu_energy() even if no inefficient OPPs have been found.
> >
> > Interesting. Do you have measurements showing the benefits on wake-up
> > duration? I remember doing so by hacking the wake-up path to force tasks
> > into feec()/compute_energy() even when overutilized, and then running
> > hackbench. Maybe something like that would work for you?
> >
> > Just want to make sure we actually need all that complexity -- while
> > it's good to reduce the asymptotic complexity, we're looking at a rather
> > small problem (max 30 OPPs or so I expect?), so other effects may be
> > dominating. Simply skipping inefficient OPPs could be implemented in a
> > much simpler way I think.
> >
> > Thanks,
> > Quentin
>
> On the Pixel4, I used rt-app to generate a task whom duty cycle is getting
> higher for each phase. Then for each rt-app task placement, I measured how long
> find_energy_efficient_cpu() took to run. I repeated the operation several
> times to increase the count. Here's what I've got:
>
> ┌────────┬─────────────┬───────┬────────────────┬───────────────┬───────────────┐
> │ Phase │ duty-cycle │ CPU │ w/o LUT │ w/ LUT │ │
> │ │ │ ├────────┬───────┼───────┬───────┤ Diff │
> │ │ │ │ Mean │ count │ Mean │ count │ │
> ├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
> │ 0 │ 12.5% │ Little│ 10791 │ 3124 │ 10657 │ 3741 │ -1.2% -134ns │
> ├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
> │ 1 │ 25% │ Mid │ 2924 │ 3097 │ 2894 │ 3740 │ -1% -30ns │
> ├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
> │ 2 │ 37.5% │ Mid │ 2207 │ 3104 │ 2162 │ 3740 │ -2% -45ns │
> ├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
> │ 3 │ 50% │ Mid │ 1897 │ 3119 │ 1864 │ 3717 │ -1.7% -33ns │
> ├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
> │ │ │ Mid │ 1700 │ 396 │ 1609 │ 1232 │ -5.4% -91ns │
> │ 4 │ 62.5% ├───────┼────────┼───────┼───────┼───────┼───────────────┤
> │ │ │ Big │ 1187 │ 2729 │ 1129 │ 2518 │ -4.9% -58ns │
> ├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
> │ 5 │ 75% │ Big │ 984 │ 3124 │ 900 │ 3693 │ -8.5% -84ns │
> └────────┴─────────────┴───────┴────────┴───────┴───────┴───────┴───────────────┘
Thanks for that. Do you have the stddev handy?
> Notice:
>
> * The CPU column describes which CPU ran the find_energy_efficient()
> function.
>
> * I modified my patch so that no inefficient OPPs are reported. This is to
> have a fairer comparison between the original table walk and the lookup
> table.
You mean to avoid the impact of the frequency selection itself? Maybe
pinning the frequencies in the cpufreq policy could do?
>
> * I removed from the table results that didn't have enough count to be
> statistically significant.
Anyways, this looks like a small but consistent gain throughout, so it's a
win for the LUT :)
Thanks,
Quentin
next prev parent reply other threads:[~2021-04-23 16:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 17:10 [PATCH] PM / EM: Inefficient OPPs detection Vincent Donnefort
2021-04-08 17:10 ` Vincent Donnefort
2021-04-15 13:12 ` Quentin Perret
2021-04-15 14:12 ` Vincent Donnefort
2021-04-15 15:04 ` Quentin Perret
2021-04-15 15:27 ` Vincent Donnefort
2021-04-22 15:36 ` Vincent Donnefort
2021-04-23 16:14 ` Quentin Perret [this message]
2021-04-28 14:46 ` Vincent Donnefort
2021-05-20 11:12 ` Quentin Perret
2021-04-15 13:16 ` Quentin Perret
2021-04-15 14:34 ` Vincent Donnefort
2021-04-15 14:59 ` Quentin Perret
2021-04-15 15:05 ` Quentin Perret
2021-04-15 15:14 ` Vincent Donnefort
2021-04-15 15:20 ` Quentin Perret
2021-04-15 15:32 ` Lukasz Luba
2021-04-15 15:43 ` Quentin Perret
2021-04-28 13:28 ` Vincent Donnefort
2021-04-22 17:26 ` Lukasz Luba
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=YILydL1QDxvuiFde@google.com \
--to=qperret@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=ionela.voinescu@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=vincent.donnefort@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).