linux-kernel - Re: [PATCH] PM / EM: Inefficient OPPs detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210428132812.GA71893@e120877-lin.cambridge.arm.com>
Date:   Wed, 28 Apr 2021 14:28:32 +0100
From:   Vincent Donnefort <vincent.donnefort@....com>
To:     Quentin Perret <qperret@...gle.com>
Cc:     Lukasz Luba <lukasz.luba@....com>, peterz@...radead.org,
        rjw@...ysocki.net, viresh.kumar@...aro.org,
        vincent.guittot@...aro.org, linux-kernel@...r.kernel.org,
        ionela.voinescu@....com, dietmar.eggemann@....com
Subject: Re: [PATCH] PM / EM: Inefficient OPPs detection

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