Re: [PATCH v3 2/2] cpufreq: CPPC: Change FIE default

[Lukasz Luba <lukasz.luba@arm.com>]

Hi Viresh,

+CC Dietmar, Morten and Souvik

On 8/24/22 07:14, Viresh Kumar wrote:
> On 18-08-22, 16:16, Jeremy Linton wrote:
>> FIE is mostly implemented as PCC mailboxes on arm machines.  This was
>> enabled by default without any data suggesting that it does anything
>> but hurt system performance. Lets change the default to 'n' until
>> hardware appears which clearly benefits.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>>   drivers/cpufreq/Kconfig.arm | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index 954749afb5fe..ad66d8f15db0 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -22,7 +22,7 @@ config ACPI_CPPC_CPUFREQ
>>   config ACPI_CPPC_CPUFREQ_FIE
>>   	bool "Frequency Invariance support for CPPC cpufreq driver"
>>   	depends on ACPI_CPPC_CPUFREQ && GENERIC_ARCH_TOPOLOGY
>> -	default y
>> +	default n
>>   	help
>>   	  This extends frequency invariance support in the CPPC cpufreq driver,
>>   	  by using CPPC delivered and reference performance counters.
> 
> Why is this required after we have the first patch in ?
> 

There are a few issues with this ACPI_CPPC_CPUFREQ_FIE solution:
1. The design is very heavy and that kernel thread can be ~512 util
    (that's what we have been told by one of our partners from servers'
    world)
2. The HW & FW design is not suited for this task. Newer HW will just
    have AMU counters (on Arm64) for FIE
3. The patches haven't been tested in terms of performance overhead
    AFAIK. Although, it affects existing Arm64 servers with their
    workloads.
4. AFAIK non of our server partners wasn't complaining about issues with
    old FIE mechanism.

In our team we are not allowed to send code that we cannot prove in many
ways.

I would just not compile this at all (or even revert this feature).
If someone compiled in this by accident - make sure we disable it
after checks like in the patch 1/2. I'll add also some comments
to that patch.

Regards,
Lukasz