Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1800148pxu; Thu, 8 Oct 2020 23:11:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoBHP6//9IdUNAN0hktFjZbcJT0msOdV+uAJSK3XApEEFbSeqxVAbu0JBq8aPGB5r8m4Ff X-Received: by 2002:a17:906:170e:: with SMTP id c14mr12464148eje.275.1602223882419; Thu, 08 Oct 2020 23:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602223882; cv=none; d=google.com; s=arc-20160816; b=NhovXlus7TKLN611+J1BLSwnsJMb/4w+alUmjyaWnXea9ipacRK3MhrNNjtsKWTths Z6z9Ht8mIBAgzWtk93zRm9xzlgV7XkNddDY98MOmar+V8HdKfCOwyZjEl9G+Rk5RGPnJ O3CZ5l0E7RhmgcfSChnK5DpB5Ay6Nkn5FeEvxRAr5nDGZR4sQx1OeyZY4lZwplpuAtg6 AvEr+JkozeTjTkwRegVl1BUWf+SeVtyHdRIPhVaSawmt/+Ge0p+d4Hc52XE78vOGaPIX Fv5eK6C0Zx2RVGdElsKvKvAkCsaAVipqeoowcguNRJFyJoILLMX9gcuva9tVj0uE4ZOT +lrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :ironport-sdr:ironport-sdr; bh=OQ+TCyLgQXcLHPe14Kd4HQpJ0lZ/7qRVlcEuG4UGWDg=; b=iF6BV+hWxaR5Zvy6yUEuVoKcmh1Jobv9dXaMh7tQ5kBM6Pc4bBmFfjnAFVmopd2ilb ezAuXCn27VMqzaT/d2z9PCulPHki/h+RVIVLXUkqbszm2gLjKMZhJQWMh0Z5vRR6WbUG FqojM3N2QeMgS//qMxEu/XlN7+Dz2TT95Hpd2jm7kU/DR1hgY2xRFJm+wZ9nLMMRkYyN ssJdDpr7hL9uFb7pozYgNfrcEAqUoU3gui4RXCRSjyBDTpA04PdA66Lwr1q63V/FQg/J Ry1lIvu1BHWz3KxuJcTArybC2wtM3JFzxbYce5sPe8W9N7uCc0U6SeodfNanBmWpUYpe 5Z5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si4774118eja.14.2020.10.08.23.10.57; Thu, 08 Oct 2020 23:11:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731577AbgJIDrI (ORCPT + 99 others); Thu, 8 Oct 2020 23:47:08 -0400 Received: from mga07.intel.com ([134.134.136.100]:45050 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727181AbgJIDrE (ORCPT ); Thu, 8 Oct 2020 23:47:04 -0400 IronPort-SDR: F077Jr5OoVg0nqG/mvl27ElFGhSYWneGSNjw3OqKq9ZAr2gXQSRt8WKOM1gzpOznCR1ToUWVUe UoZFx6ZKXuTQ== X-IronPort-AV: E=McAfee;i="6000,8403,9768"; a="229624611" X-IronPort-AV: E=Sophos;i="5.77,353,1596524400"; d="scan'208";a="229624611" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2020 20:47:03 -0700 IronPort-SDR: 8pzXGi/5bXFkGJAoJ22yWbHBmItVfVqSQt2Dh/be408N1Vo/492DiaQeDUwQqik80o7Bw85QBg OCFyiAbwiWZA== X-IronPort-AV: E=Sophos;i="5.77,353,1596524400"; d="scan'208";a="519574637" Received: from unknown (HELO rzhang1-mobile) ([10.255.29.238]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2020 20:46:58 -0700 Message-ID: Subject: Re: [PATCH v2 3/4] powercap: Add AMD Fam17h RAPL support From: Zhang Rui To: Kim Phillips , "Rafael J . Wysocki" , Victor Ding , linux-pm@vger.kernel.org Cc: Alexander Shishkin , Borislav Petkov , Daniel Lezcano , "H. Peter Anvin" , Ingo Molnar , Josh Poimboeuf , Pawan Gupta , "Peter Zijlstra (Intel)" , Sean Christopherson , Thomas Gleixner , Tony Luck , Vineela Tummalapalli , LKML , x86@kernel.org Date: Fri, 09 Oct 2020 11:46:55 +0800 In-Reply-To: <20201007161439.312534-4-kim.phillips@amd.com> References: <20201007161439.312534-1-kim.phillips@amd.com> <20201007161439.312534-4-kim.phillips@amd.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2020-10-07 at 11:14 -0500, Kim Phillips wrote: > From: Victor Ding > > This patch enables AMD Fam17h RAPL support for the power capping > framework. The support is as per AMD Fam17h Model31h (Zen2) and > model 00-ffh (Zen1) PPR. > > Tested by comparing the results of following two sysfs entries and > the > values directly read from corresponding MSRs via /dev/cpu/[x]/msr: > /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj > /sys/class/powercap/intel-rapl/intel-rapl:0/intel- > rapl:0:0/energy_uj > > Signed-off-by: Victor Ding > Acked-by: Kim Phillips > Cc: Victor Ding > Cc: Alexander Shishkin > Cc: Borislav Petkov > Cc: Daniel Lezcano > Cc: "H. Peter Anvin" > Cc: Ingo Molnar > Cc: Josh Poimboeuf > Cc: Pawan Gupta > Cc: "Peter Zijlstra (Intel)" > Cc: "Rafael J. Wysocki" > Cc: Sean Christopherson > Cc: Thomas Gleixner > Cc: Tony Luck > Cc: Vineela Tummalapalli > Cc: LKML > Cc: linux-pm@vger.kernel.org > Cc: x86@kernel.org > --- > Kim's changes from Victor's original submission: > > https://lore.kernel.org/lkml/20200729205144.3.I01b89fb23d7498521c84cfdf417450cbbfca46bb@changeid/ > > - Added my Acked-by. > - Added Daniel Lezcano to Cc. > > arch/x86/include/asm/msr-index.h | 1 + > drivers/powercap/intel_rapl_common.c | 2 ++ > drivers/powercap/intel_rapl_msr.c | 27 > ++++++++++++++++++++++++++- > 3 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/msr-index.h > b/arch/x86/include/asm/msr-index.h > index f1b24f1b774d..c0646f69d2a5 100644 > --- a/arch/x86/include/asm/msr-index.h > +++ b/arch/x86/include/asm/msr-index.h > @@ -324,6 +324,7 @@ > #define MSR_PP1_POLICY 0x00000642 > > #define MSR_AMD_RAPL_POWER_UNIT 0xc0010299 > +#define MSR_AMD_CORE_ENERGY_STATUS 0xc001029a > #define MSR_AMD_PKG_ENERGY_STATUS 0xc001029b > > /* Config TDP MSRs */ > diff --git a/drivers/powercap/intel_rapl_common.c > b/drivers/powercap/intel_rapl_common.c > index 983d75bd5bd1..6905ccffcec3 100644 > --- a/drivers/powercap/intel_rapl_common.c > +++ b/drivers/powercap/intel_rapl_common.c > @@ -1054,6 +1054,8 @@ static const struct x86_cpu_id rapl_ids[] > __initconst = { > > X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL, &rapl_defaults_hsw_se > rver), > X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM, &rapl_defaults_hsw_se > rver), > + > + X86_MATCH_VENDOR_FAM(AMD, 0x17, &rapl_defaults_core), I double if we can use rapl_defaults_core here. static const struct rapl_defaults rapl_defaults_core = { .floor_freq_reg_addr = 0, .check_unit = rapl_check_unit_core, .set_floor_freq = set_floor_freq_default, .compute_time_window = rapl_compute_time_window_core, }; .floor_freq_reg_addr = 0, is redundant here, even for rapl_defaults_core, we can remove it. .check_unit = rapl_check_unit_core, the Intel UNIT MSR supports three units including Energy/Power/Time. From the change below, only the energy counter is supported, so you may need to confirm if all the three units are supported or not. .set_floor_freq = set_floor_freq_default,this function sets PL1_CLAMP bit on RAPL_DOMAIN_REG_LIMIT, but RAPL_DOMAIN_REG_LIMIT is not supported on the AMD cpus. .compute_time_window = rapl_compute_time_window_core, this is used for setting the power limits, which is not supported on the AMD cpus. IMO, it's better to use a new rapl_defaults that contains valid callbacks for AMD cpus. > {} > }; > MODULE_DEVICE_TABLE(x86cpu, rapl_ids); > diff --git a/drivers/powercap/intel_rapl_msr.c > b/drivers/powercap/intel_rapl_msr.c > index c68ef5e4e1c4..dcaef917f79d 100644 > --- a/drivers/powercap/intel_rapl_msr.c > +++ b/drivers/powercap/intel_rapl_msr.c > @@ -48,6 +48,21 @@ static struct rapl_if_priv rapl_msr_priv_intel = { > .limits[RAPL_DOMAIN_PACKAGE] = 2, > }; > > +static struct rapl_if_priv rapl_msr_priv_amd = { > + .reg_unit = MSR_AMD_RAPL_POWER_UNIT, > + .regs[RAPL_DOMAIN_PACKAGE] = { > + 0, MSR_AMD_PKG_ENERGY_STATUS, 0, 0, 0 }, > + .regs[RAPL_DOMAIN_PP0] = { > + 0, MSR_AMD_CORE_ENERGY_STATUS, 0, 0, 0 }, > + .regs[RAPL_DOMAIN_PP1] = { > + 0, 0, 0, 0, 0 }, > + .regs[RAPL_DOMAIN_DRAM] = { > + 0, 0, 0, 0, 0 }, > + .regs[RAPL_DOMAIN_PLATFORM] = { > + 0, 0, 0, 0, 0}, I don't think you need to set the PP1/DRAM/PLATFORM registers to 0 explicitly if they are not supported. > + .limits[RAPL_DOMAIN_PACKAGE] = 1, Is Pkg Domain PL1 really supported? At least according to this patch, I don't think so. So if power limit is supported, it is better to add the support in this patch altogether. If no, we're actually exposing energy counters only. If this is the case, I'm not sure if it is proper to do this in powercap class because we can not do powercap actually. Or at least, if we want to support power zones with no power limits, we should enhance the code to support this rather than fake a power limit. thanks, rui > +}; > + > /* Handles CPU hotplug on multi-socket systems. > * If a CPU goes online as the first CPU of the physical package > * we add the RAPL package to the system. Similarly, when the last > @@ -137,7 +152,17 @@ static int rapl_msr_probe(struct platform_device > *pdev) > const struct x86_cpu_id *id = x86_match_cpu(pl4_support_ids); > int ret; > > - rapl_msr_priv = &rapl_msr_priv_intel; > + switch (boot_cpu_data.x86_vendor) { > + case X86_VENDOR_INTEL: > + rapl_msr_priv = &rapl_msr_priv_intel; > + break; > + case X86_VENDOR_AMD: > + rapl_msr_priv = &rapl_msr_priv_amd; > + break; > + default: > + pr_err("intel-rapl does not support CPU vendor %d\n", > boot_cpu_data.x86_vendor); > + return -ENODEV; > + } > rapl_msr_priv->read_raw = rapl_msr_read_raw; > rapl_msr_priv->write_raw = rapl_msr_write_raw; > IF