linux-kernel - Re: [PATCH v3 08/10] perf/x86/rapl: Modify the generic variable names to *

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]

Message-ID: <9f99286e-b840-4c50-8ff4-a25f2d2fdc67@amd.com>
Date: Wed, 3 Jul 2024 12:01:10 +0530
From: Dhananjay Ugwekar <Dhananjay.Ugwekar@....com>
To: "Zhang, Rui" <rui.zhang@...el.com>,
 "peterz@...radead.org" <peterz@...radead.org>
Cc: "gautham.shenoy@....com" <gautham.shenoy@....com>,
 "alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
 "ananth.narayan@....com" <ananth.narayan@....com>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "ravi.bangoria@....com" <ravi.bangoria@....com>,
 "Hunter, Adrian" <adrian.hunter@...el.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "mingo@...hat.com" <mingo@...hat.com>,
 "oleksandr@...alenko.name" <oleksandr@...alenko.name>,
 "irogers@...gle.com" <irogers@...gle.com>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "gustavoars@...nel.org" <gustavoars@...nel.org>,
 "kan.liang@...ux.intel.com" <kan.liang@...ux.intel.com>,
 "kees@...nel.org" <kees@...nel.org>,
 "sandipan.das@....com" <sandipan.das@....com>,
 "mark.rutland@....com" <mark.rutland@....com>,
 "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
 "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
 "bp@...en8.de" <bp@...en8.de>, "acme@...nel.org" <acme@...nel.org>,
 "kprateek.nayak@....com" <kprateek.nayak@....com>,
 "jolsa@...nel.org" <jolsa@...nel.org>,
 "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
 "x86@...nel.org" <x86@...nel.org>, "namhyung@...nel.org"
 <namhyung@...nel.org>
Subject: Re: [PATCH v3 08/10] perf/x86/rapl: Modify the generic variable names
 to *_pkg*

Hi Rui,

On 7/3/2024 9:37 AM, Zhang, Rui wrote:
> On Tue, 2024-07-02 at 15:50 +0530, Dhananjay Ugwekar wrote:
>>
>>>
>>> For Intel products, we have
>>> 1. Casecadelake-AP which has multi-die per package and has per-die
>>> RAPL
>>> MSRs
>>> 2. all other platforms which has single-die per package, so its
>>> RAPL
>>> MSRs can be considered as either package-scope or die-scope
>>> This applies to Thermal MSRs as well.
>>>
>>> so for these MSRs, we can treat them as
>>> 1. always die-scope for all existing platforms
>>> or
>>> 2. package-scope with the exception of Casecadelake-ap
>>> And current kernel code follows rule 1.
>>>
>>> I propose we switch to rule 2 for these code because rule 1 can be
>>> broke on future multi-die systems (This is already true for Thermal
>>> MSRs).
>>
>> I have a doubt about this, won't the future Intel multi-die systems 
>> have die-scope for the RAPL PMU like Casecadelake-AP?
> 
> For future multi-die systems that I know, the RAPL is still package
> scope 

I think in that case we can go with rule 2, it would be future proof
for Intel systems. If you agree, I can make the change in next version.

Something like below?,

-#define rapl_pmu_is_pkg_scope()                         \
-        (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||  \                                                                                                                                                                  
-	 boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)

+#define rapl_pmu_is_die_scope()			\
+	(boot_cpu_data.x86_model_id == CASCADELAKE)

Regards,
Dhananjay

but it is just lucky that RAPL control is not exposed via the
> MSRs so rule 1 is not actually broke for RAPL PMU (while it is indeed
> broken for other drivers like thermal).
> 
> In short, if we stick with rule 1, the RAPL PMU still works. Switching> to rule 2 to be consistent with the other drivers is also a choice IMV.> 
> thanks,
> rui
>>
>> If yes, then rule 1 above seems better.
>>
>> Regards,
>> Dhananjay
>>
>>>
>>> In this sense, I think it is okay to call it pkg level rapl for
>>> both
>>> Intel and AMD.
>>>
>>> thanks,
>>> rui
>>>
>