linux-kernel - Re: [PATCH v5 00/22] cpufreq: introduce a new AMD CPU frequency control mechanism

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]
Date:   Thu, 16 Dec 2021 19:20:34 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Huang Rui <ray.huang@....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>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        Linux PM <linux-pm@...r.kernel.org>,
        Deepak Sharma <deepak.sharma@....com>,
        Alex Deucher <alexander.deucher@....com>,
        Mario Limonciello <mario.limonciello@....com>,
        Steven Noonan <steven@...vesoftware.com>,
        Nathan Fontenot <nathan.fontenot@....com>,
        Jinzhou Su <Jinzhou.Su@....com>,
        Xiaojian Du <Xiaojian.Du@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v5 00/22] cpufreq: introduce a new AMD CPU frequency
 control mechanism

On Tue, Nov 30, 2021 at 1:37 PM Huang Rui <ray.huang@....com> wrote:
>
> Hi all,
>
> We would like to introduce a new AMD CPU frequency control mechanism as the
> "amd-pstate" driver for modern 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.
>
> "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_CPPC feature flag to distinguish the different types.
>
> Using the new AMD P-States method + kernel governors (*schedutil*,
> *ondemand*, ...) to manage the frequency update is the most appropriate
> bridge between AMD Zen based hardware processor and Linux kernel, the
> processor is able to adjust to the most efficiency frequency according to
> the kernel scheduler loading.
>
> Please check the detailed CPU feature and MSR register description in
> Processor Programming Reference (PPR) for AMD Family 19h Model 51h,
> Revision A1 Processors:
>
> https://www.amd.com/system/files/TechDocs/56569-A1-PUB.zip
>
> Performance Per Watt (PPW) Calculation:
>
> We use the RAPL interface with "perf" tool to get the energy data of the
> package power.
>
> The data comparisons between amd-pstate and acpi-freq module are tested on
> AMD Cezanne processor (mobile CPU):
>
> 1) TBench CPU benchmark:
>
> +----------------------------------------------------------------------------------------------+
> |                                                                                              |
> |                               TBench4 (Performance Per Watt)                                 |
> |                                                                             Higher is better |
> +-------------------+------------------------+------------------------+------------------------+
> |                   |  Performance Per Watt  |  Performance Per Watt  |  Performance Per Watt  |
> |   Kernel Module   |       (Schedutil)      |       (Ondemand)       |       (Performance)    |
> |                   |       Unit: MB / J     |       Unit: MB / J     |       Unit: MB / J     |
> +-------------------+------------------------+------------------------+------------------------+
> |                   |                        |                        |                        |
> |    acpi-cpufreq   |         48.56          |        48.89           |        47.81           |
> |                   |                        |                        |                        |
> +-------------------+------------------------+------------------------+------------------------+
> |                   |                        |                        |                        |
> |     amd-pstate    |         48.38          |        47.38           |        48.77           |
> |                   |                        |                        |                        |
> +-------------------+------------------------+------------------------+------------------------+
>
> Note: The previous data was based on TBench2, as align with Suse, we use
> TBench4 to re-test it. The PPW is very closed to acpi-cpufreq. And we are
> still re-runing other tests.
>
> Steam Game Demo on Ryzen 5900X (12 core 24 threads):
>
> The picture to compare acpi-cpufreq vs amd-pstate:
> https://drive.google.com/file/d/1PvSduykJn9U5MMOhzFWycnbmGmznalM3/view?usp=sharing
>
> Two videos:
> https://drive.google.com/file/d/1nQQEteL-v_zQxnOJpyW8JqvRW2FFDN2Z/view?usp=sharing
> https://drive.google.com/file/d/1heuPgFG71SQHvGb6wfedrQciBfE2rhnu/view?usp=sharing
>
> Actually, the amd-pstate driver doesn't change the physical maximum
> frequency capacity in the processor. But it's able to provide the finer
> grain performance control range instead of legacy 3 P-States. It has a
> better performance and power efficiency than before. We will continue
> optimize amd-pstate function on kernel governors to support different types
> of processors such as mobile latop, performance desktop, and etc.
>
> See patch series in below git repo:
> V1: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=amd-pstate-dev-v1
> V2: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=amd-pstate-dev-v2
> V3: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=amd-pstate-dev-v3
> V4: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=amd-pstate-dev-v4
> V5: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=amd-pstate-dev-v5
>
> For details introduction, please see the patch 22.

After going through all of the series I'm still unsure what the
freq_qos requests added in patch [06/22] are for.

The cpupower patches need ACKs from Shuah for me to take them.

The tracing patch needs an ACK from Steve Rostedt.

Thanks!