From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95CC9C742D7 for ; Sat, 13 Jul 2019 10:46:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6EF3C20838 for ; Sat, 13 Jul 2019 10:46:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="roABZ5It" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727489AbfGMKqp (ORCPT ); Sat, 13 Jul 2019 06:46:45 -0400 Received: from merlin.infradead.org ([205.233.59.134]:38696 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726460AbfGMKqo (ORCPT ); Sat, 13 Jul 2019 06:46:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qA92BokuQwIpfUgsOngEYZTp77wWyZRJldi5ki7ucGw=; b=roABZ5It4KusJQ35a/CptUJMq J2ybOivTMeJO3f3eHAcguMk4nkFtL4X1EM2LEXev+K9U+wnPf5Kx8/pY7BZWG+ZqllmmJL6jIHJJ+ QQWGDKGipwLqOktHGfYoga1l5tGTMam7yPN22WZuOTEY3apy8dMV2zw6pu91eeNCdVu5gqI8QyiJL qIB+9nCLap8IbQQlzktu4IC9Gxutj5BZfru9tFr88w+qczynnzCx4ncQ58omSyy9y6bdZEjN7E8i4 txdV62ktTQXFNKomgQ0To/CRQ9fB01Fy1g4Yg3ZXGkg1P2YzyH0lQX9hzDL0wCJ2pOAVwW/gIWPE1 DSmvkZBow==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92 #3 (Red Hat Linux)) id 1hmFXq-00063x-1v; Sat, 13 Jul 2019 10:46:22 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 5999B20B51DA5; Sat, 13 Jul 2019 12:46:19 +0200 (CEST) Date: Sat, 13 Jul 2019 12:46:19 +0200 From: Peter Zijlstra To: "Natarajan, Janakarajan" Cc: "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "devel@acpica.org" , "Rafael J . Wysocki" , Len Brown , Viresh Kumar , Robert Moore , Erik Schmauss , "Ghannam, Yazen" Subject: Re: [PATCHv3 0/6] CPPC optional registers AMD support Message-ID: <20190713104619.GA3496@hirez.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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/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. > TODO: > * 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.