[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250617133333.GU1613376@noisy.programming.kicks-ass.net>
Date: Tue, 17 Jun 2025 15:33:33 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Mi, Dapeng" <dapeng1.mi@...ux.intel.com>
Cc: kan.liang@...ux.intel.com, 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,
ak@...ux.intel.com, zide.chen@...el.com
Subject: Re: [RFC PATCH 06/12] perf: Support extension of sample_regs
On Tue, Jun 17, 2025 at 08:14:36PM +0800, Mi, Dapeng wrote:
> > We're going to do a sane SIMD register set with variable width, and
> > reclaim the XMM regs from the normal set.
>
> Ok, so we need to add two width variables like
> sample_ext_regs_words_intr/user,
s/ext/simd/
Not sure it makes sense to have separate vector widths for kernel and
user regs, but sure.
> then reuse the XMM regs bitmap to represent the extend regs bitmap.
But its not extended; its the normal bitmap.
> Considering the OPMASK regs and APX
> extended GPRs have same bit-width (64 bits), we may have to combine them
> into a single bitmap, e.g. bits[15:0] represents R31~R16 and bits[23:16]
> represents OPMASK7 ~ OPMASK0.
Again confused, bits 0:23 are the normal registers (in a lunatic
order). The XMM regs are in 32:63 and will be free if the SIMD thing is
present.
SPP+APX should definitely go there.
Not sure about OPMASK; those really do belong with the SIMD state. Let
me go figure out what ARM and Risc-V look like in more detail.
Powered by blists - more mailing lists