linux-kernel - Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20170418103818.GQ28191@vireshk-i7>
Date:   Tue, 18 Apr 2017 16:08:18 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Eduardo Valentin <edubezval@...il.com>
Cc:     Javi Merino <javi.merino@...nel.org>,
        Zhang Rui <rui.zhang@...el.com>,
        linaro-kernel@...ts.linaro.org,
        Amit Daniel Kachhap <amit.kachhap@...il.com>,
        Rafael Wysocki <rjw@...ysocki.net>, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with
 cpufreq core

On 17-04-17, 10:34, Eduardo Valentin wrote:
> Hey,
> 
> On Mon, Apr 17, 2017 at 11:31:45AM +0530, Viresh Kumar wrote:
> > Hi Guys,
> > 
> > The cpu_cooling driver is designed to use CPU frequency scaling to avoid
> > high thermal states for a platform. But it wasn't glued really well with
> > cpufreq core.
> > 
> > This series tries to improve interactions between cpufreq core and
> > cpu_cooling driver and does some fixes/cleanups to the cpu_cooling
> > driver.
> 
> 
> Can you please be more specific of what exactly is not gluing
> properly/really well? I like refactoring, as long as well justified.
> 
> Do you see anything broken currently?

It wasn't broken really but the same information is scattered around
and it wasn't clear on which one is the best one refer. For example,
clipped-cpus is copied from the policy structure, but the policy->cpus
thing can get updated later on, while the clipped-cpus never got
updated. It makes more sense to get rid of the copies we are keeping
and reuse the real fields, i.e. use the cpufreq policy directly in
cpu_cooling.

And then it caused lots of cleanups as well..

> > I have tested it on ARM 32 (exynos) and 64 bit (hikey) boards and have
> > pushed them for 0-day build bot and kernel CI testing as well. We should
> > know if something is broken with these.
> 
> Nice. What governors did you try? Have you checked "power_allocator" by
> any chance?

I tried setting all the governors including power_allocator on my
exynos board, and didn't see anything broken. My branch also got
tested by kernel CI bot for build and boot tests on a wide range of
ARM boards and I didn't see any bad reports due to this set. So it
should be okay.

> > 
> > @Javi: It would be good if you can give them a test, specially because
> > of your work on the "power" specific bits in the driver.
> > 
> 
> 
> @Javi, are you still around? This needs to be validated in terms of how
> the cdev states and power models are computed. Just to make sure we are
> in one piece. Copying the ARM folks too, Punit?.

And yes, I specifically wanted Javi (or some other ARM guy) to test
this stuff out. Looks like Lukasz will help out now.

Thanks to all of you :)

-- 
viresh