linux-kernel - Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist

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]

Date:   Thu, 14 Oct 2021 20:43:50 +0900
From:   Hector Martin <marcan@...can.st>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Sibi Sankar <sibis@...eaurora.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Sven Peter <sven@...npeter.dev>, Marc Zyngier <maz@...nel.org>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Catalin Marinas <catalin.marinas@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does
 not exist

On 14/10/2021 18.55, Ulf Hansson wrote:
> Yes, this sounds like you should move away from modeling the memory
> part as a parent genpd for the CPUs' genpd.
> 
> As Viresh pointed out, a devfreq driver seems like a better way to do
> this. As a matter of fact, there are already devfreq drivers that do
> this, unless I am mistaken.
> 
> It looks like devfreq providers are listening to opp/cpufreq
> notifiers, as to get an indication of when it could make sense to
> change a performance state.
> 
> In some cases the devfreq provider is also modeled as an interconnect
> provider, allowing consumers to specify memory bandwidth constraints,
> which may trigger a new performance state to be set for the memory
> controller.
> 
> In the tegra case, the memory controller is modelled as an
> interconnect provider and the devfreq node is modelled as an
> interconnect-consumer of the memory controller. Perhaps this can work
> for apple SoCs too?

I was poking around and noticed the OPP core can already integrate with 
interconnect requirements, so perhaps the memory controller can be an 
interconnect provider, and the CPU nodes can directly reference it as a 
consumer? This seems like a more accurate model of what the hardware 
does, and I think I saw some devices doing this already.

(only problem is I have no idea of the actual bandwidth numbers involved 
here... I'll have to run some benchmarks to make sure this isn't just 
completely dummy data)

> 
> That said, perhaps as an option to move forward, we can try to get the
> cpufreq pieces solved first. Then as a step on top, add the
> performance scaling for the memory controller?

Sure; that's a pretty much independent part of this patchset, though I'm 
thinking I might as well try some things out for v2 anyway; if it looks 
like it'll take longer we can split it out and do just the cpufreq side.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub