[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250617142952.GX1613376@noisy.programming.kicks-ass.net>
Date: Tue, 17 Jun 2025 16:29:52 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: mingo@...hat.com, acme@...nel.org, namhyung@...nel.org,
tglx@...utronix.de, dave.hansen@...ux.intel.com, irogers@...gle.com,
adrian.hunter@...el.com, jolsa@...nel.org,
alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
dapeng1.mi@...ux.intel.com, ak@...ux.intel.com, zide.chen@...el.com
Subject: Re: [RFC PATCH 00/12] Support vector and more extended registers in
perf
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.
> 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, 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).
If you want an explicit bit, we might as well use one from __reserved_1,
we still have some left.
Powered by blists - more mailing lists