Received-SPF: pass (google.com: domain of linux-kernel+bounces-165386-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 1 May 2024 07:46:26 -0700
From: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
To: Viresh Kumar <viresh.kumar@linaro.org>, 
	Beata Michalska <beata.michalska@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	ionela.voinescu@arm.com, sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com, 
	vincent.guittot@linaro.org, sumitg@nvidia.com, yang@os.amperecomputing.com, 
	lihuisong@huawei.com
Subject: Re: Re: [PATCH v4 4/4] cpufreq: Use arch specific feedback for
 cpuinfo_cur_freq
Message-ID: <sjm6ktvjql5ce5icfqaxlwvql2jchpya6pgtr6jkjiodztpcno@p5kse5mwqwbl>
References: <20240405133319.859813-1-beata.michalska@arm.com>
 <20240405133319.859813-5-beata.michalska@arm.com>
 <76zutrz47zs6i2cquvjo2qn7myxpq7e3c6alhper7n3wrkhf5h@22l5t5pio2cd>
 <Zh6dSrUnckoa-thV@arm.com>
 <s2bel7fzwpkyfyfkhod4xaihuklsaum75ycbcgmcanqaezxdu7@uxvqdqt3yo7l>
 <ZiuF0zgqkMlmkEZz@arm.com>
 <20240429092515.2ehk4ifcul6mbaxh@vireshk-i7>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20240429092515.2ehk4ifcul6mbaxh@vireshk-i7>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?hxVZZqaMuOARFeeQW4XaiXfpDIuNPd4G6JS9WNJNIonvq8jDxU351n0dH5h/?=
 =?us-ascii?Q?em+WwEbijgTkRDA0yqaJm7w/KfwOpsOkwE0yb7zwZOld3kkirwXZ30PcK9cW?=
 =?us-ascii?Q?qMJpn1jZ34oZxdgYgncVZ8svuOJp4/zArSkbWHhWrs46+nXhYCHklnInmJdE?=
 =?us-ascii?Q?eBO/Es/d5zG1W6tQCCskR/3x5A6V0Sp0pIrYJK2DpqY+aCBnuYx9PC49vBP4?=
 =?us-ascii?Q?Gq+VQhdr5Me+BVWNk391oCSddH8D6y9uP9F6nosDvYu3bGxLCKivtP6Rjtsp?=
 =?us-ascii?Q?zBwi0iTvM3YWc378gQ0NbWXDfp0lt3nNkRqbAZ46JtvjwRvfFstph9WWaQph?=
 =?us-ascii?Q?mMhLFqxG575YKhB2ZVzkCmblTGST2JG1Z4BAfOQUibb7BtupVkeqaUhG6r4x?=
 =?us-ascii?Q?EnWErceM1gliRoimrs/3U0IJa6WOcw8idp7LPWh3LKFDCjHr6FzFZNXJ+ENH?=
 =?us-ascii?Q?la0DodrY0F0tJHjf4nQKpfqbhFE1hWZZZt+n093iq+Eaabu9l5FFoGWlWjFH?=
 =?us-ascii?Q?rPI3URLU3eesNnFm66z8RazRlu4JSj0SQ15KTYVBHrk+3c+5ACBmKn3+AaPE?=
 =?us-ascii?Q?8AugND7KMjsOYBGkKXh8fZwt/UALXfYR2gVA8QTVrniuj053/jMaOzUUkgQZ?=
 =?us-ascii?Q?NyRJ1Q+qta5m4xw4g2LGQ9pBPmIgwFA+7LnMVLMWb/Ir2U9xZMG7BUuW/reD?=
 =?us-ascii?Q?BTNPz+fJHingFYAGDvW/TAWFxH9oSEPsc2sNhm/IBm7uPyLGStC3Rqeay53B?=
 =?us-ascii?Q?UUtDTdtkCbpZ08cW4Rw3aTieEka+wwJ6Q9wmgy4mKq6x9/j0h8J8UkzsRY6F?=
 =?us-ascii?Q?quIFz4EraBk/iyFm4nM+gCa2T8cbYRwbUP6YjY9r4dR436pXK081XWQ0OvDg?=
 =?us-ascii?Q?WvWgx9x0JNf3JD3+oYkcr23+8VFbZGh55lIts9POKXC/YpCFPfdTEIB+Abil?=
 =?us-ascii?Q?6GdwmUpfinq8SBnOEsJmxfCUUoGxBv3oWGCST1cZDqkl0J+rxbPCPHZICOs4?=
 =?us-ascii?Q?VGMavS8ycLRBmZlm5UVKfQPdSIH2l+o6kvOMupIzk5vfEDKnDr5rF7Vx3gLP?=
 =?us-ascii?Q?5XpEeVlQqRejR2TSgzWLaAQNVCk3izquyL/hA4fzmBYkEPRHiFRl9pZ5oJ9J?=
 =?us-ascii?Q?FsZ7kl8rjfpjQgAj4VrYdjSb3Tq4AloWXVXAsRvLJ6P3Qkly8xnbkET6I43Y?=
 =?us-ascii?Q?mdWTsP4x4dK1mFQCeEmthSHSw0ppBtGddHkBYF3glrA85speLRckhuiGjOE7?=
 =?us-ascii?Q?xra1Tu9oM8abF/iHeisN6RgvW7S7gT4XJFl4H/uPUIDgP7xkgVprnmIaKTKl?=
 =?us-ascii?Q?lFFZIC2vRHXBxtHzwQsJBUH1X/EjG3YZNIhf2cnSKIaN3AZs1ksUkOTBrrIV?=
 =?us-ascii?Q?3Cq8QILgJ6pLpdPJcp+pQ54tnyoX2560CAH0I7J5Qv2futuCX4Qnyrrxyrnq?=
 =?us-ascii?Q?lhEwthtp/5npjNqKAjQvbKwPUpbUQcjkEeMiU/JfoaS4An8enAqm8Yvvpspa?=
 =?us-ascii?Q?IvjwajltLv70KVbPeTmF+UPkRQG5Cwyt75KxyrWxmUECtHarzj68iUi9BsWD?=
 =?us-ascii?Q?gFwhcUvHaZN5ghmZ/i6Am2AKWKGmKzZoOjOFuyhcgTuyzkEVMebcTKp4/fDG?=
 =?us-ascii?Q?QMqxt4CxdatEMGnAH3qFRVLjkcu9gl/jK0/Ke4jb8dNo?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d9a59f9b-803f-484a-a303-08dc69ed7bfb
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR01MB6509.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2024 14:46:29.0472
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: qU9dkFCGQA+Uv1FkEr+tU2UFE/JPsncfBRnQRFZqNNnif+vADRqwEIFamhZi6DmaJAwUInkRLlHZdT7/LSwHdAOofYetXg1nfiYoP5xDex3QB/v59E9qv4oBqVA+kC1P
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR01MB7390

On Mon, Apr 29, 2024 at 02:55:15PM +0530, Viresh Kumar wrote:
>On 26-04-24, 12:45, Beata Michalska wrote:
>> It seems that we might need to revisit the discussion we've had around
>> scaling_cur_freq and cpuinfo_cur_freq and the use of arch_freq_get_on_cpu.
>> As Vanshi has raised, having both utilizing arch specific feedback for
>> getting current frequency is bit problematic and might be confusing at best.
>> As arch_freq_get_on_cpu is already used by show_scaling_cur_freq there are not
>> many options we are left with, if we want to kee all archs aligned:
>> we can either try to rework show_scaling_cur_freq and it's use of
>> arch_freq_get_on_cpu, and move it to cpuinfo_cur_freq, which would align with
>> relevant docs, though that will not work for x86, or we keep it only there and
>> skip updating cpuinfo_cur_freq, going against the guidelines. Other options,
>> purely theoretical, would involve making arch_freq_get_on_cpu aware of type of
>> the info requested (hw vs sw) or adding yet another arch-specific implementation,
>> and those are not really appealing alternatives to say at least.
>> What's your opinion on this one ?
>
>Hi Beata / Vanshidhar,
>
>Lets forget for once what X86 and ARM may have done and think about it
>once again. I also had a chat with Vincent today about this.
>
>The documentation says it clearly, cpuinfo_cur_freq is the one
>received from hardware and scaling_cur_freq is the one requested from
>software.
>
>Now, I know that X86 has made both of them quite similar and I
>suggested to make them all aligned (and never received a reply on my
>previous message).
>
>There are few reasons why it may be worth keeping the definition (and
>behavior) of the sysfs files as is, at least for ARM:
>- First is that the documentation says so.
>- There is no point providing the same information via both the
>  interfaces, there are two interfaces here for a reason.
>- There maybe tools around which depend on the documented behavior.
>- From userspace, currently there is only one way to know the exact
>  frequency that the cpufreq governors have requested from a platform,
>  i.e. the value from scaling_cur_freq. If we make it similar to
>  cpuinfo_cur_freq, then userspace will never know about the requested
>  frequency and the eventual one and if they are same or different.
>
>Lets keep the behavior as is and update only cpuinfo_cur_freq with
>arch_freq_get_on_cpu().
>
>Makes sense ?

I had the same concerns. It probably makes sense explicity note this in
the next version of the patch series; in the future readers may be
confused by x86 and ARM behave differntly on scaling_cur_freq.

Thanks,
Vanshi

>
>-- 
>viresh