linux-kernel - Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

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: <20180608131104.GA7838@e108498-lin.cambridge.arm.com>
Date:   Fri, 8 Jun 2018 14:11:04 +0100
From:   Quentin Perret <quentin.perret@....com>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     Juri Lelli <juri.lelli@...hat.com>, peterz@...radead.org,
        rjw@...ysocki.net, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        mingo@...hat.com, morten.rasmussen@....com, chris.redpath@....com,
        patrick.bellasi@....com, valentin.schneider@....com,
        vincent.guittot@...aro.org, thara.gopinath@...aro.org,
        viresh.kumar@...aro.org, tkjos@...gle.com, joelaf@...gle.com,
        smuckle@...gle.com, adharmap@...cinc.com, skannan@...cinc.com,
        pkondeti@...eaurora.org, edubezval@...il.com,
        srinivas.pandruvada@...ux.intel.com, currojerez@...eup.net,
        javi.merino@...nel.org
Subject: Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management
 framework

On Friday 08 Jun 2018 at 14:39:33 (+0200), Dietmar Eggemann wrote:
> In your current '(3)* Arm/Arm64 init code' (* see at the end of this email)
> you have this dev_pm_opp_of_estimate_power() em_data_callback active_power
> function.
> 
> Let's say thermal and the task scheduler would initialize the EM
> independently. They would still end up using C from dt, and f, V and P from
> opp library in your example.

Ah, that's where the confusion comes from ... The task scheduler or
thermal _don't_ initialize the EM. They just use it if it's there.
The _drivers_ (typically, but not limited to, CPUFreq drivers)
initialize the EM. I'll try to make that clearer in the diagram for v4.

> IMHO, this information should be only provided once from one source per
> platform.

Yes, I think so too. That's why all but the first registration of the
same frequency domain is ignored.

> > > Even though we would be forced to get cpufreq's related cpumask from
> > > somewhere.
> > 
> > That's the easy part. The difficult part is, where do you get power
> > values from ? You have to let the lower layers register those values
> > in a centralized location on a voluntary basis. And then it becomes easy
> > for consumers to access that data, because they know where it is.
> 
> The code in the arch could use the same struct em_data_callback em_cb = {
> &dev_pm_opp_of_estimate_power } that the cpufreq driver is currently using?

How do you know from the arch code if you should get power from DT
with dev_pm_opp_of_estimate_power or use another callback that reads
power from firmware (SCMI) ?

I don't think it is reasonable to assume a single source of information for
an arch. It is is already an incorrect assumption even if just you look at
the Arm world.

> > Again, I don't think that's possible. You have to let the lower layers
> > tell you where the power values come from, at the very least. You could
> > let the archs do that aggregation I suppose, but I don't really see the
> > benefit over one centralized framework with a generic interface ...
> > What's your opinion ?
> 
> Don't understand the '... let the lower layers tell you where the power
> values come from ...' part. Where is the difference whether the arch or the
> cpufreq driver uses em_data_callback?

Because different CPUFreq drivers can be used for one arch. There are
different CPUFreq drivers because there are different ways of getting
information about the platform, even just for the Arm world (DT, SCPI,
SCMI, ...). It's the same thing for power values, they don't necessarily
come from DT.

The point of having a centralized EM framework with a standardized
callback prototype is flexibility. You can implement a callback that
estimates power from the DT. You can implement a callback that reads
power from firmware. But you can also have a completely ad-hoc EM
provider in a module if you like. All you have to do to provide data to
the framework is respect the callback API.

> > So I think I'll drop patch 10/10 for v4 ... That part should be
> > discussed separately, with the rest of the Arm-specific changes.
> 
> Maybe 3 clearly separated parts of the patch-set; (1) EM (2) EAS uses EM (3)
> Arm/Arm64 init code ?

Right, that sounds like the right thing to do :-)

Thanks,
Quentin