linux-kernel - Re: [PATCH v2 0/3] EM / PM: Inefficient OPPs

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: <20210526093922.txvxxgl7yvpz27iu@vireshk-i7>
Date:   Wed, 26 May 2021 15:09:22 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Vincent Donnefort <vincent.donnefort@....com>
Cc:     peterz@...radead.org, rjw@...ysocki.net,
        vincent.guittot@...aro.org, qperret@...gle.com,
        linux-kernel@...r.kernel.org, ionela.voinescu@....com,
        lukasz.luba@....com, dietmar.eggemann@....com
Subject: Re: [PATCH v2 0/3] EM / PM: Inefficient OPPs

On 26-05-21, 15:08, Viresh Kumar wrote:
> On 26-05-21, 10:01, Vincent Donnefort wrote:
> > I originally considered to add the inefficient knowledge into the CPUFreq table.
> 
> I wasn't talking about the cpufreq table here in the beginning, but calling
> dev_pm_opp_disable(), which will eventually reflect in cpufreq table as well.
> 
> > But I then gave up the idea for two reasons:
> > 
> >   * The EM depends on having schedutil enabled. I don't think that any
> >     other governor would then manage to rely on the inefficient OPPs. (also I
> >     believe Peter had a plan to keep schedutil as the one and only governor)
> 
> Right, that EM is only there for schedutil.
> 
> I would encourage if this can be done even without the EM dependency, if
> possible. It would be a good thing to do generally for any driver that wants to
> do that.

Another benefit of course is that we will have less work to do in the hotpath,
it was obvious, but I thought of stating it anyway :)

-- 
viresh