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

[Peter Zijlstra]

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.