linux-kernel - Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote callback for shared policies

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: <20170720135801.qdqm5aypsxq45wrd@hirez.programming.kicks-ass.net>
Date:   Thu, 20 Jul 2017 15:58:01 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Saravana Kannan <skannan@...eaurora.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Ingo Molnar <mingo@...hat.com>, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, smuckle.linux@...il.com,
        eas-dev@...ts.linaro.org, sudeep.holla@....com
Subject: Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote
 callback for shared policies

On Fri, Jul 14, 2017 at 10:33:20AM +0530, Viresh Kumar wrote:
> On 13-07-17, 19:02, Saravana Kannan wrote:
> > Honestly, this seems like such a chip/platform specific decision. There's no
> > reason that one can't have a chip where you can change the frequency of any
> > CPU from any other CPU. If there's such a limitation, we should let that be
> > handled at the CPU freq driver level instead of having to know about any of
> > that at the scheduler. Heck, at worst case, the CPU freq driver can send an
> > IPI and execute that work on the CPU of interest.
> > 
> > In all Qualcomm chipsets (well, at least the ones that have been used in
> > Android devices so far), we can switch the frequency of any CPU from any
> > other CPU. If we can do that even without fast switching, why wouldn't any
> > theoretical fast switching be incapable of supporting this?

I spoke with Sudeep since the last email; and the proposed interface
(SCMI) is a shmem/mailbox one, which can indeed change the frequency of
another CPU.

> > Is this a limitation specific to x86 that we are assuming all
> > architectures and platforms are going to have?

You are right in that x86 cannot do this. Sending IPIs is fairly
expensive though :/

> The default assumption in cpufreq core is that any CPU from a policy
> can change freq for that policy. Yes, we surely have cases where any
> CPU can change freq of any other CPU (even in different policies).
> Perhaps all ARM platforms are like that, not sure.
> 
> And so I added a special flag for that in my previous version, but the
> idea here is to get a simple solution merged first and then we can
> have a separate patch later to support freq switching from all CPUs.

I was going to write things about serialization here. How allowing remote
updates would require extra serialization, in part inspired by your
Changelog comment that says cpufreq-shared provides the required
serialization.

But I think that's all nonsense... That is, yes cpufreq-shared needs
additional serialization, but that's not relevant for the problem at
hand.

The thing is, all of this cpufreq_update_*() crud is called with the
relevant rq->lock held. So all those calls are already fully serialized
between CPUs.