Re: [PATCH v3 08/10] perf/x86/rapl: Modify the generic variable names to *_pkg*
From: Dhananjay Ugwekar
Date: Wed Jul 03 2024 - 02:31:42 EST
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
>>>
>