From: Vincent Donnefort <vincent.donnefort@arm.com>
To: Quentin Perret <qperret@google.com>
Cc: Lukasz Luba <lukasz.luba@arm.com>,
peterz@infradead.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
vincent.guittot@linaro.org, linux-kernel@vger.kernel.org,
ionela.voinescu@arm.com, dietmar.eggemann@arm.com
Subject: Re: [PATCH] PM / EM: Inefficient OPPs detection
Date: Wed, 28 Apr 2021 14:28:32 +0100 [thread overview]
Message-ID: <20210428132812.GA71893@e120877-lin.cambridge.arm.com> (raw)
In-Reply-To: <YHhfCr+7KztYpIkD@google.com>
On Thu, Apr 15, 2021 at 03:43:06PM +0000, Quentin Perret wrote:
> On Thursday 15 Apr 2021 at 16:32:31 (+0100), Lukasz Luba wrote:
> > Are you sure that the 'policy' can be accessed from compute_energy()?
> > It can be from schedutil freq switch path, but I'm not use about our
> > feec()..
>
> Right, I was just looking at cpufreq_cpu_get() and we'll have locking
> issue in the wake-up path :/ So maybe making feec() aware of policy caps
> is for later ...
>
> > For me this cpufreq_driver_resolve_freq sounds a bit out of this patch
> > subject.
>
> Not sure I agree -- if we're going to index the EM table from schedutil
> it should be integrated nicely if possible.
>
> Thanks
I'm having a look at this topic right now and I don't think we can skip
cpufreq_driver_resolve_freq() in the end, for two reasons:
1. It is possible to register OPPs (and by extension perf_states) for a
frequency for which, the cpufreq table entry is marked with
CPUFREQ_ENTRY_INVALID. It would probably be an issue that would have to be
fixed in the driver, but it is currently allowed.
2. More importantly, while resolving the frequency, we also cache the index in
cached_resolved_idx. Some drivers, such as qcom-cpufreq-hw rely on this
value for their fastswitch support.
--
Vincent
next prev parent reply other threads:[~2021-04-28 13:28 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
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 [this message]
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=20210428132812.GA71893@e120877-lin.cambridge.arm.com \
--to=vincent.donnefort@arm.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=qperret@google.com \
--cc=rjw@rjwysocki.net \
--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).