Re: [RFC PATCH 00/12] Support vector and more extended registers in perf
From: Mi, Dapeng
Date: Tue Jun 17 2025 - 20:57:29 EST
On 6/17/2025 11:23 PM, Liang, Kan wrote:
>
> On 2025-06-17 10:29 a.m., Peter Zijlstra wrote:
>> On Tue, Jun 17, 2025 at 09:52:12AM -0400, Liang, Kan wrote:
>>
>>> OK. So the sample_simd_reg_words actually has another meaning now.
>> Well, any simd field being non-zero means userspace knows about it. Sort
>> of an implicit flag.
> Yes, but the tool probably wouldn't to touch any simd fields if user
> doesn't ask for simd registers
>
>>> It's used as a flag to tell whether utilizing the old format.
>>>
>>> If so, I think it may be better to have a dedicate sample_simd_reg_flag
>>> field.
>>>
>>> For example,
>>>
>>> #define SAMPLE_SIMD_FLAGS_FORMAT_LEGACY 0x0
>>> #define SAMPLE_SIMD_FLAGS_FORMAT_WORDS 0x1
>>>
>>> __u8 sample_simd_reg_flags;
>>> __u8 sample_simd_reg_words;
>>> __u64 sample_simd_reg_intr;
>>> __u64 sample_simd_reg_user;
>>>
>>> If (sample_simd_reg_flags != 0) reclaims the XMM space for APX and SPP.
>>>
>>> Does it make sense?
Not sure if I missed some discussion, but are these fields only intended
for SIMD regs? What about the APX extended GPRs? Suppose APX eGPRs can
reuse the legacy XMM bitmaps in sample_regs_user/intr[47:32], but we need
an extra flag to distinguish it's XMM regs or APX eGPRs, maybe add an extra
bit sample_egpr_reg : 1 in sample_simd_reg_words, but the *simd* word in
the name would become ambiguous.
>> Not sure, it eats up a whole byte. Dapeng seemed to favour separate
>> intr/user vector width (although I'm not quite sure what the use would
>> be).
The reason that I prefer to add 2 separate "words" item is that user could
sample interrupt and user space SIMD regs (but with different bit-width)
simultaneously in theory, like "--intr-regs=YMM0, --user-regs=XMM0".
>>
>> If you want an explicit bit, we might as well use one from __reserved_1,
>> we still have some left.
> OK. I may add a sample_simd_reg : 1 to explicitly tell kernel to utilize
> the sample_simd_reg_XXX.
>
> Thanks,
> Kan