linux-kernel - Re: [PATCH V3 3/3] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping

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]

Date:   Thu, 25 Apr 2019 13:50:36 +0100
From:   Quentin Perret <quentin.perret@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Thara Gopinath <thara.gopinath@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Zhang Rui <rui.zhang@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Amit Kachhap <amit.kachhap@...il.com>,
        viresh kumar <viresh.kumar@...aro.org>,
        Javi Merino <javi.merino@...nel.org>,
        Eduardo Valentin <edubezval@...il.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Nicolas Dechesne <nicolas.dechesne@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>
Subject: Re: [PATCH V3 3/3] thermal/cpu-cooling: Update thermal pressure in
 case of a maximum frequency capping

On Thursday 25 Apr 2019 at 14:04:10 (+0200), Vincent Guittot wrote:
> On Thu, 25 Apr 2019 at 12:45, Quentin Perret <quentin.perret@....com> wrote:
> >
> > On Tuesday 23 Apr 2019 at 18:38:46 (-0400), Thara Gopinath wrote:
> > > I think there is one major difference between user-defined frequency
> > > constraints and frequency constraints due to thermal events in terms of
> > > the time period the system spends in the the constraint state.
> > > Typically, a user constraint lasts for seconds if not minutes and I
> > > think in this case cpu_capacity_orig should reflect this constraint and
> > > not cpu_capacity like this patch set.
> >
> > That might not always be true I think. There's tons of userspace thermal
> > deamons out there, and I wouldn't be suprised if they were writing into
> > the cpufreq sysfs files, although I'm not sure.
> 
> They would better use the sysfs set_target interface of cpu_cooling
> device in this case.

Right

> > Another thing is, if you want to change the capacity_orig value, you'll
> > need to rebuild the sched domains and all I believe. Otherwise there is
> > a risk to 'break' the sd_asym flags. So we need to make sure we're happy
> > to pay that price.
> 
> That would be the goal, if userspace uses the sysfs interface of
> cpufreq to set a new max frequency, it should be considered as a long
> change in regards to the scheduling rate and in this case it should be
> interesting to update cpacity_orig and rebuild sched_domain.

I guess as long as we don't rebuild too frequently that could work.
Perhaps we could put some rate limiting in there to enforce that. Though
we don't do it for hotplug so ... :/