[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAP-5=fVmVnFQOp82rdrnq=cLiQq+jq0fLJXUWGwV+Q+U+yHwTQ@mail.gmail.com>
Date: Mon, 26 Jan 2026 09:17:04 -0800
From: Ian Rogers <irogers@...gle.com>
To: "Mi, Dapeng" <dapeng1.mi@...ux.intel.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org, Zide Chen <zide.chen@...el.com>,
Falcon Thomas <thomas.falcon@...el.com>, Dapeng Mi <dapeng1.mi@...el.com>,
Xudong Hao <xudong.hao@...el.com>
Subject: Re: [RFC Patch] perf regs: Remove __weak attribute from perf-regs functions
On Sun, Jan 25, 2026 at 9:20 PM Mi, Dapeng <dapeng1.mi@...ux.intel.com> wrote:
>
>
> On 1/24/2026 8:39 AM, Ian Rogers wrote:
> > On Fri, Jan 23, 2026 at 1:13 AM Dapeng Mi <dapeng1.mi@...ux.intel.com> wrote:
[snip]
> >> diff --git a/tools/arch/arm64/include/uapi/asm/perf_regs.h b/tools/arch/arm64/include/uapi/asm/perf_regs.h
> >> index 86e556429e0e..43e8e08f52ed 100644
> >> --- a/tools/arch/arm64/include/uapi/asm/perf_regs.h
> >> +++ b/tools/arch/arm64/include/uapi/asm/perf_regs.h
> >> @@ -43,6 +43,6 @@ enum perf_event_arm_regs {
> >> PERF_REG_ARM64_EXTENDED_MAX
> >> };
> >>
> >> -#define PERF_REG_EXTENDED_MASK (1ULL << PERF_REG_ARM64_VG)
> >> +#define PERF_ARM64_REG_EXTENDED_MASK (1ULL << PERF_REG_ARM64_VG)
> > I think avoiding the conflicts by adding the architecture name is correct.
>
> Yes, but the side effect is that there would be mismatch with the
> corresponding kernel header file. Not sure if someone dislike it ...
It should be possible to update the kernel headers too rather than
have them out-of-sync with the perf ones. Someone might object but it
doesn't seem unreasonable to make the changes to me :-)
> >
> >> Additionally, there could be architecture-specific instructions called,
> >> such as the "mfspr" instruction on PowerPC, which causes build errors on
> >> other platforms like x86.
> > Right, the mfspr is used to add additional registers into the mask and
> > if we're not on a powerpc and can't run it we should assume something
> > conservative which your change will achieve. Fwiw, I tried to see if
> > similar information was available from say the ELF header, but I
> > couldn't see it.
> >
> > With your SIMD changes and common functions you can refactor the
> > function signature to take the e_machine and also the perf ABI enum
> > value, then the mapping of either an XMM register string or SSP should
> > be possible by varying the ABI enum value. You'll also know to fix up
> > all the callers on the reading perf.data side to pass the enum value
> > as the code won't compile with the missing parameter.
>
> Yes, if we decide to use this way, the SIMD/eGPRs support would follow same
> way.
Great, thanks.
[snip]
> > I think it would be nice for the SDT clean up to be a distinct patch
> > from the arch__user_reg_mask/arch__intr_reg_mask clean up. If there
> > are regressions it will be easier to bisect.
>
> Sure. Would split them in V2.
Thanks!
Ian
Powered by blists - more mailing lists