[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2892e7a-65c4-4744-a611-6fc3c1d37cd3@amd.com>
Date: Tue, 16 Dec 2025 10:12:35 +0530
From: Ravi Bangoria <ravi.bangoria@....com>
To: Dapeng Mi <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>, Thomas Gleixner <tglx@...utronix.de>, Dave Hansen
<dave.hansen@...ux.intel.com>, Ian Rogers <irogers@...gle.com>, Adrian Hunter
<adrian.hunter@...el.com>, Jiri Olsa <jolsa@...nel.org>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, Andi Kleen <ak@...ux.intel.com>,
Eranian Stephane <eranian@...gle.com>, Mark Rutland <mark.rutland@....com>,
<broonie@...nel.org>, <linux-kernel@...r.kernel.org>,
<linux-perf-users@...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>, Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [Patch v5 00/19] Support SIMD/eGPRs/SSP registers sampling for
perf
Hi Dapeng,
> While the hardware solution remains preferable due to its lower
> overhead and higher accuracy, this software approach provides a
> viable alternative.
Lower accuracy in the software approach is due to the delay in an NMI
delivery which will make the SIMD data misaligned a bit? Something like:
insn1
insn2 -> Overflow. RIP, GPRs captured by PEBS and NMI triggered
insn3
insn4
insn5 -> NMI delivered here, so SIMD regs are captured here?
insn6
Am I interpreting it correctly?
Thanks,
Ravi
Powered by blists - more mailing lists