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

[Peter Zijlstra]

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.