linux-kernel - Re: [PATCH 04/19] cpufreq: amd: introduce a new amd pstate driver to support future processors

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: <20210913111828.GD3731830@hr-amd>
Date:   Mon, 13 Sep 2021 19:18:28 +0800
From:   Huang Rui <ray.huang@....com>
To:     "Fontenot, Nathan" <Nathan.Fontenot@....com>
CC:     "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        "Borislav Petkov" <bp@...e.de>, Ingo Molnar <mingo@...nel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "Sharma, Deepak" <Deepak.Sharma@....com>,
        "Deucher, Alexander" <Alexander.Deucher@....com>,
        "Limonciello, Mario" <Mario.Limonciello@....com>,
        "Su, Jinzhou (Joe)" <Jinzhou.Su@....com>,
        "Du, Xiaojian" <Xiaojian.Du@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 04/19] cpufreq: amd: introduce a new amd pstate driver to
 support future processors

On Fri, Sep 10, 2021 at 03:31:26AM +0800, Fontenot, Nathan wrote:
> 
> On 9/8/2021 9:59 AM, Huang Rui wrote:
> > amd-pstate is the AMD CPU performance scaling driver that introduces a
> > new CPU frequency control mechanism on AMD Zen based CPU series in Linux
> > kernel. The new mechanism is based on Collaborative processor
> > performance control (CPPC) which is finer grain frequency management
> > than legacy ACPI hardware P-States. Current AMD CPU platforms are using
> > the ACPI P-states driver to manage CPU frequency and clocks with
> > switching only in 3 P-states. AMD P-States is to replace the ACPI
> > P-states controls, allows a flexible, low-latency interface for the
> > Linux kernel to directly communicate the performance hints to hardware.
> >
> 
> This patch seems like it is just enabling CPPC on AMD and not a new mechanism
> based on CPPC. Can you clarify?
> 
> Also, if this is just enabling CPPC, shouldn't the driver be named something
> like amd_cppc and not amd_pstate? This isn't using P-states.

That's just a name. We use the "amd-pstate" to indicate the new driver that
use the kernel governors such as schedutil and others for frequency
control. And "amd_cppc" indicates the legacy solution with userspace tool
for frequency control.

>  
> > "amd-pstate" leverages the Linux kernel governors such as *schedutil*,
> > *ondemand*, etc. to manage the performance hints which are provided by CPPC
> > hardware functionality. The first version for amd-pstate is to support one
> > of the Zen3 processors, and we will support more in future after we verify
> > the hardware and SBIOS functionalities.
> > 
> > There are two types of hardware implementations for amd-pstate: one is full
> > MSR support and another is shared memory support. It can use
> > X86_FEATURE_AMD_CPPC_EXT feature flag to distinguish the different types.
> >
> 
> Looking at the drivers/acpi code for CPPC I don't think this distinction
> between MSRs and shared memory requires a feature flag. Shouldn't this be
> handled properly in cpc_read|write if the ACPI tables are set up correctly?
> Please correct me if I'm wrong.

MSR registers can be used for implementing the fast switch function which
has the better performance on schedutil and other governors.

> 
> This would also remove the need for the additional indirection pointed
> out by Peter.
> 
> Could you also provide an explanation as to why a new CPPC driver is need
> instead of updating the existing cppc_cpufreq driver.
> 

Good question, I had explained these in last mail with Peter.

Thanks,
Ray