Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3005206yba; Tue, 16 Apr 2019 02:36:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqzvwnZADQ26iz6rAxieQfZD/0ZgvSNafVVrTWw65ld16YyObYBb/vJoc0y55VXA+G7c6OYL X-Received: by 2002:a62:14d7:: with SMTP id 206mr79614021pfu.162.1555407382472; Tue, 16 Apr 2019 02:36:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555407382; cv=none; d=google.com; s=arc-20160816; b=0adLq3jI6vdDWSzq62hROX6WWgrWzUetZAF7AYyyZrfGSdXqHOEQ4HR7743pvJI0js K1Y8B3FT7OyG8sJL3kmyY64vlv8qT+Wp4t+GM1UxgvvzR4sQiXH5gHsCwvbxkp/96Cst w6XREku+6VInhQrqW3AS14/XwUZ6M38eDeR/KE95rIqWNBE1lC9XNYUxzq/JgH/a+IQv fVfD/48KogZs3MbjKRQ4VpU0eo8uVSZuoJhKfsIIY5k3xka+XY04dvsbKYyitUKdJPsu sY8ZlmYommUNUZOsLiY/V68c7ZIHNY0olE6ao23ZFJcopTMxEekO+W1Ke4h+mdN5jutW 7FOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=8qw/OL5mJ45U4+FG/qyIj2foiwTJOtRvVs5qYVtrnvk=; b=jSBArkWJXsorntcsGRtT7OhIs1LoOvc5vI+r0dEbn9LzLM9rFtQ9EBiUAypVnQVYoS lObebu+NteEW2u/FqKOnKFdGu3TY1EagYI2WPbZXe5CJVtgLR5qdetl3ZMHAI3+3Z2+T Rza/A7xlLorW1BLECnH3k8ZhAiF9Ac2jkBYmpaXH1er78SeTDKCIdtzhi52Yd26Ac0kx XuCyruyb4x7Tg2UKRqMdiM9yAhFVMJjaUIT/rPKeEA7r0taJ4UNDGKVyPWG6Pb1wIqFn HDf+li4PdRksG1jU878acnnLYf6VoG44oHo1xhtE+ZJPlgyT4YLHjJ0FVAXwuY5CMcH/ iJmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v77si50215140pfa.219.2019.04.16.02.36.06; Tue, 16 Apr 2019 02:36:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728936AbfDPJeW (ORCPT + 99 others); Tue, 16 Apr 2019 05:34:22 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:44802 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728230AbfDPJeT (ORCPT ); Tue, 16 Apr 2019 05:34:19 -0400 Received: by mail-ot1-f67.google.com with SMTP id d24so16996021otl.11; Tue, 16 Apr 2019 02:34:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8qw/OL5mJ45U4+FG/qyIj2foiwTJOtRvVs5qYVtrnvk=; b=UzeJuUdt6dSythzI4sp+wCC75nm87K3e3BnIF7NsLXdki3iQb6OLjoLcjnRkrOX/Dp ma23MtVXaiD+U0OBckFfZKEaK2tAUAVrbW9x7pKQZFYpWnQWfIHYcSrHiUEjU573EVTI rsS3XF0CEp8cyqmlSnBFhl5Y09DSN+NXTSWkx2YVVPj5UZsP42/F/grra6f9xSezXEnu nYeN1ldORhr3ge0WItcztVOKunuXI9wUbx8A90GLl++corTeP8mezq7UUF4ps5YW24a3 tE1AcVEIvrirrhf6yPoyKH79BjoMzJJxxuCXNaF6S+6hePWhT6ACuGQglbhH3Jsax354 1TMA== X-Gm-Message-State: APjAAAXfqH7FR4eyili56TDkB27R0ZcoCqC9v+Uzr+XK/cMJGMCjPAMV dthpQ6OYy0tXRHUFifdO9x25SDZYTifTNRFkcGo= X-Received: by 2002:a9d:4b11:: with SMTP id q17mr14587035otf.272.1555407258468; Tue, 16 Apr 2019 02:34:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 16 Apr 2019 11:34:07 +0200 Message-ID: Subject: Re: [PATCH v2 0/7] CPPC optional registers AMD support To: Janakarajan Natarajan Cc: "Natarajan, Janakarajan" , "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" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 16, 2019 at 12:35 AM Janakarajan Natarajan wrote: > > On 4/4/19 4:25 PM, 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 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 > > > > The CPPC driver is updated to enable the OSPM and the userspace to > > access > > the newly supported registers. > > > > The purpose of exposing the registers via the sysfs entries is to allow > > the userspace to: > > * Tweak the values to fit its workload. > > * Apply a profile from AMD's optimization guides. > > > > Profiles will be documented in the performance/optimization guides. > > > > Note: > > * AMD systems will not have a policy applied in the kernel at this time. > > * By default, acpi_cpufreq will still be used. > > > > TODO: > > * Create a linux userspace tool that will help users generate a CPPC > > * profile > > for their target workload. > > * Create or update a driver to apply a general CPPC policy in the > > * kernel. > > > > v1->v2: > > * Add macro to ensure BUFFER only registers have BUFFER type. > > * Add support macro to make the right check based on register type. > > * Remove support checks for registers which are mandatory. > > > Are there any concerns regarding this patchset? Yes, there are. Unfortunately, it is generally problematic. First off, the behavior of existing sysfs files cannot be changed at will, as there may be users of them out there already depending on the current behavior. Second, at least some CPPC control registers are used by cpufreq drivers (cppc_cpufreq and intel_pstate), so modifying them behind the drivers' backs is not a good idea in general. For this reason, adding new sysfs attributes to allow user space to do that is quite questionable. Thanks, Rafael