lkml.org 
[lkml]   [2020]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 0/3] CPUFreq: Add support for cpu performance dependencies
From
Date
Hi Viresh, thanks for looking into this.

On 11/3/20 10:18 AM, Viresh Kumar wrote:
> On 02-11-20, 12:01, Nicola Mazzucato wrote:
>> Hi All,
>>
>> In this V3 posting I have replaced the new dt-binding with minor changes/
>> improvements for opp (since we are now using opp tables instead).
>> The RFC still stands on how to make this info available to sw consumers.
>>
>> In the RFC, I am proposing a simple addition of a performance dependencies
>> cpumask in CPUFreq core and an example of how drivers and consumers would
>> make use of it.
>> I also propose an alternative approach, which does not require changes in
>> CPUFreq core, but - possibly - in all the consumers.
>>
>> This is to support systems where exposed cpu performance controls are more
>> fine-grained that the platform's ability to scale cpus independently.
>
> I was talking to Vincent about what you are doing here and we got a
> bit confused and so here are few questions that we had:
>
> - Based on my previous understanding, you don't want software
> coordination of frequencies (which is done by cpufreq today), but
> want the hardware to do that and so you want per-cpu cpufreq
> policies.

Correct. And this has been done for quite some time in some platforms.

>
> - What's the real benefit of hardware coordination ? Want to make sure
> I fully understand that.

The hardware coordination that is coming out by having per-cpu cpufreq policies
is not new, and works just fine in most of the systems.

The benefit of having per-cpu controls is that the firmware will take care of
the performance of the entire system. It is purely a delegation to firmware for
the performance optimizations.

>
> - Because of hardware co-ordination of otherwise co-ordinated CPUs,
> few things break. Thermal and EAS are some of the examples and so
> you are trying to fix them here by proving them the missing
> information again.

Correct. And for this I have proposed two ways.

>
> - One other thing that breaks with this is freq-invariance in the
> scheduler, as the scheduler won't see the real frequencies the
> various CPUs are running at. Most of the hardware we have today
> doesn't have counters, like AMUs, not sure if all future ones based
> on SCMI will have that too, so how are they gong to be fixed ?
>

Correct. freq-invariance without counters is trying to do its best based on the
information it has available. It definitely relies on the knowledge of the v/f
domains to work at its best so I think in the case of per-cpu it will follow the
same approach as others being affected (EAS, thermal).

> And if we even have to fix this (freq invariance), what's hardware
> coordination giving us that makes all this worth it ?

I suppose this is more a generic question for all the platforms running with h/w
coordination, but for our case is that the f/w will take care of the performance
optimizations for us :)

>
> Sorry about the long list :)

No problem at all. Thank you for your time on this and I hope I have made bits
clearer.

Nicola

>

\
 
 \ /
  Last update: 2020-11-04 19:03    [W:0.125 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site