linux-kernel - Re: [PATCH v6 3/3] perf stat: Add no-affinity flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAP-5=fU2YLHpK_BymOM-J8mdbw2Pzhx+2Khpppi-OCCctxhYYw@mail.gmail.com>
Date: Thu, 8 Jan 2026 14:30:41 -0800
From: Ian Rogers <irogers@...gle.com>
To: Andi Kleen <ak@...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>, 
	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, 
	Dapeng Mi <dapeng1.mi@...ux.intel.com>
Subject: Re: [PATCH v6 3/3] perf stat: Add no-affinity flag

On Thu, Jan 8, 2026 at 2:07 PM Andi Kleen <ak@...ux.intel.com> wrote:
>
> On Thu, Jan 08, 2026 at 01:26:52PM -0800, Ian Rogers wrote:
> > Add flag that disables affinity behavior. Using sched_setaffinity to
> > place a perf thread on a CPU can avoid certain interprocessor
> > interrupts but may introduce a delay due to the scheduling,
> > particularly on loaded machines. Add a command line option to disable
> > the behavior. This behavior is less present in other tools like `perf
> > record`, as it uses a ring buffer and doesn't make repeated system
> > calls.
>
> I thought we had agreed that this change isn't needed?

This patch or the series? My last feedback was:
https://lore.kernel.org/lkml/CAP-5=fUvsF7RtLAKaMwc28CeSEOJ+j0gVwvQN59moOnUS=kWVg@mail.gmail.com/

So the code as-is is trying to always use setaffinity. For a single
syscall on a particular CPU this is unlikely to be profitable on a
machine under load, the IPI will happen faster. You mentioned that
realtime priorities could address this but that this also required
capabilities. I didn't see that as something that contradicted the use
of these patches.

The point of the flag in this change is so that the IPI behavior can
be had should issues with CPU affinities be experienced. With how the
code is refactored we can also make the existing "always use
affinities" behavior an option by modifying evlist__use_affinity, but
given the cost of an IPI should be less than that of migrating a
thread it doesn't seem like this option would be useful - you could
also make the code do this by adding a dummy event as >1 event
triggers the setaffinity behavior.

Anyway, I think we still want these changes that successfully fixed a
customer issue I had. The already merged patches do improve things,
and I think we can do yet more, but the real cause of the delay in
reading counters was the calls to setaffinity and this being slow on
loaded machines. The patches make it so setaffinity doesn't happen if
there is just a single IPI being saved or if requested on the command
line.

Thanks,
Ian

> -Andi