[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAP-5=fVQqfKwij1GV56136bY9xNVz_tveKQWFCS5o7eP7W8bUw@mail.gmail.com>
Date: Tue, 3 Feb 2026 15:31:49 -0800
From: Ian Rogers <irogers@...gle.com>
To: Andres Freund <andres@...razel.de>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>, "Dr. David Alan Gilbert" <linux@...blig.org>,
Yang Li <yang.lee@...ux.alibaba.com>, James Clark <james.clark@...aro.org>,
Thomas Falcon <thomas.falcon@...el.com>, Thomas Richter <tmricht@...ux.ibm.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Andi Kleen <ak@...ux.intel.com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>
Subject: Re: [PATCH v4 07/10] perf tool_pmu: More accurately set the cpus for
tool events
On Tue, Feb 3, 2026 at 3:27 PM Andres Freund <andres@...razel.de> wrote:
>
> Hi,
>
> On 2026-02-03 15:05:39 -0800, Ian Rogers wrote:
> > Thanks for the bug report! There were changes in v6.19 to change how
> > metrics were computed hence the fault in the metric computation. The
> > bisected patch is at fault, it aims to compute the CPU maps for tool
> > events in a way to avoid unnecessary sched setaffinity calls. By
> > having a smaller CPU map it set up a situation with user CPUs where
> > the tool events could have no CPUs, removed from the list of events
> > and the later seg fault occurred.
>
> Thanks for the quick reply!
>
> > I sent out a new patch series:
> > https://lore.kernel.org/linux-perf-users/20260203225129.4077140-1-irogers@google.com/
> > that has a revert of this patch, a fix to correctly avoid the segfault in
> > the prepare_metric function, and a new patch to properly reduce the CPU maps
> > of the tool events. The remaining affinity reduction patches are still part
> > of the series and I believe ready to land.
>
> That sounds like it's targeted for 6.20? I assume the revert on its own needs
> to land in 6.19 (or stable if too late for 6.19) somehow?
Yeah, the maintainers are the ones creating the pull requests and can do this.
Thanks,
Ian
> Greetings,
>
> Andres Freund
Powered by blists - more mailing lists