Linux-PM Archive on
 help / color / Atom feed
From: Peter Zijlstra <>
To: "Natarajan, Janakarajan" <>
Cc: "" <>,
	"" <>,
	"" <>,
	"" <>,
	"Rafael J . Wysocki" <>,
	Len Brown <>,
	Viresh Kumar <>,
	Robert Moore <>,
	Erik Schmauss <>,
	"Ghannam, Yazen" <>
Subject: Re: [PATCHv3 0/6] CPPC optional registers AMD support
Date: Sat, 13 Jul 2019 12:46:19 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jul 10, 2019 at 06:37:09PM +0000, Natarajan, Janakarajan wrote:
> CPPC (Collaborative Processor Performance Control) offers optional
> registers which can be used to tune the system based on energy and/or
> performance requirements.
> Newer AMD processors (>= Family 17h) add support for a subset of these
> optional CPPC registers, based on ACPI v6.1.
> The following are the supported CPPC registers for which sysfs entries
> are created:
> * enable                (NEW)
> * max_perf              (NEW)
> * min_perf              (NEW)
> * energy_perf
> * lowest_perf
> * nominal_perf
> * desired_perf          (NEW)
> * feedback_ctrs
> * auto_sel_enable       (NEW)
> * lowest_nonlinear_perf
> First, update cppc_acpi to create sysfs entries only when the optional
> registers are known to be supported.
> Next, a new CPUFreq driver is introduced to enable the OSPM and the userspace
> to access the newly supported registers through sysfs entries found in
> /sys/devices/system/cpu/cpu<num>/amd_cpufreq/.
> This new CPUFreq driver can only be used by providing a module parameter,
> amd_cpufreq.cppc_enable=1.
> The purpose of exposing the registers via the amd-cpufreq sysfs entries is to
> allow the userspace to:
> * Tweak the values to fit its workload.
> * Apply a profile from AMD's optimization guides.

So in general I think it is a huge mistake to expose all that to
userspace. Before you know it, there's tools that actually rely on it,
and then inhibit the kernel from doing anything sane with it.

> Profiles will be documented in the performance/optimization guides.

I don't think userspace can really do anything sane with this; it lacks
much if not all useful information.

> Note:
> * AMD systems will not have a policy applied in the kernel at this time.

And why the heck not? We're trying to move all cpufreq into the
scheduler and have only a single governor, namely schedutil -- yes,
we're still stuck with legacy, and we're still working on performance
parity in some cases, but I really hope to get rid of all other cpufreq
governors eventually.

And if you look at schedutil (schedutil_cpu_util in specific) then
you'll see it is already prepared for CPPC and currently only held back
by the generic cpufreq interface.

It currently only sets desired freq, it has information for
min/guaranteed, and once we get thermal intergrated we might have
sensible data for max freq too.

> * Create a linux userspace tool that will help users generate a CPPC profile
>   for their target workload.

Basically a big fat NAK for this approach to cpufreq.

> * Create a general CPPC policy in the kernel.

We already have that, sorta.

  parent reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 18:37 Natarajan, Janakarajan
2019-07-10 18:37 ` [PATCHv3 1/6] acpi/cppc: Add macros for CPPC register checks Natarajan, Janakarajan
2019-07-10 18:37 ` [PATCHv3 2/6] acpi/cppc: Ensure only supported CPPC sysfs entries are created Natarajan, Janakarajan
2019-07-10 18:37 ` [PATCHv3 3/6] acpi/cppc: Rework cppc_set_perf() to use cppc_regs index Natarajan, Janakarajan
2019-07-10 18:37 ` [PATCHv3 4/6] acpi/cppc: Add support for optional CPPC registers Natarajan, Janakarajan
2019-07-10 18:37 ` [PATCHv3 5/6] acpi/cppc: Add support for CPPC Enable register Natarajan, Janakarajan
2019-07-10 18:37 ` [PATCHv3 6/6] drivers/cpufreq: Add a CPUFreq driver for AMD processors (Fam17h and later) Natarajan, Janakarajan
2019-07-11  6:12   ` Viresh Kumar
2019-07-11 16:58     ` Janakarajan Natarajan
2019-07-12  3:10       ` Viresh Kumar
2019-07-12 16:44         ` Janakarajan Natarajan
2019-07-13 10:46 ` Peter Zijlstra [this message]
2019-07-15 17:57   ` [PATCHv3 0/6] CPPC optional registers AMD support Ghannam, Yazen

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PM Archive on

Archives are clonable:
	git clone --mirror linux-pm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pm linux-pm/ \
	public-inbox-index linux-pm

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox