linux-kernel - Re: [PATCH v1 0/7] perf bench: Add qspinlock benchmark

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: <20250916203839.GB2800598@noisy.programming.kicks-ass.net>
Date: Tue, 16 Sep 2025 22:38:39 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Mark Rutland <mark.rutland@....com>, Yuzhuo Jing <yuzhuo@...gle.com>,
	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>,
	Liang Kan <kan.liang@...ux.intel.com>, Yuzhuo Jing <yzj@...ch.edu>,
	Andrea Parri <parri.andrea@...il.com>,
	Palmer Dabbelt <palmer@...osinc.com>,
	Charlie Jenkins <charlie@...osinc.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Kumar Kartikeya Dwivedi <memxor@...il.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Barret Rhoden <brho@...gle.com>,
	Alexandre Ghiti <alexghiti@...osinc.com>,
	Guo Ren <guoren@...nel.org>, linux-kernel@...r.kernel.org,
	linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v1 0/7] perf bench: Add qspinlock benchmark

On Tue, Sep 16, 2025 at 10:00:13AM -0700, Ian Rogers wrote:

> The inspiration for adding a benchmark this way comes from the
> existing perf bench memcpy benchmark. The reason to care is that, as
> with memcpy, there are subtle effects from things like RISC-V's
> non-temporal atomics (ARM near-far atomics) and the size of CPU cores.

But the patch as proposed was very much x86 only. No RISC-V or ARM64
support.

> In general queued spinlock is preferred in the kernel, a benchmark of
> queued spinlock and ticket spinlock may reveal that ticket spinlock
> would be a better default for certain configurations.

And didn't do ticket, even though we have a generic implementation in
the kernel too (IIRC I have a few patches for that as well.. someday I
might have time).

And yeah, ticket is very good and hard to beat for 'smaller' systems.

There is a reason for commit: a8ad07e5240c :-)

> Does it make sense to have this in perf? It makes it easier to tune
> the implementations, keep code in sync with the kernel, etc. Does it
> make sense for perf to have a memcpy benchmark? Maybe not these days
> of having a more reliable rep movsb. Anyway, in general the bar to
> getting things into perf bench hasn't been hugely high and I don't see
> disagreement that on some occasions a benchmark like this is useful.
> As someone who cares about this kind of performance tuning, I care
> about having the benchmark.

Yeah, not convinced we should stuff all that in perf. But also, the
benchmark doesn't actually seem to do what you say you wanted, so meh.