From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Juergen Gross <jgross@suse.com>,
Ajay Kaher <ajay.kaher@broadcom.com>,
Alexey Makhalov <alexey.makhalov@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Thomas Gleixner <tglx@kernel.org>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Arnd Bergmann <arnd@arndb.de>, Dennis Zhou <dennis@kernel.org>,
Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
virtualization@lists.linux.dev, linux-arch@vger.kernel.org,
linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org,
kernel-team@meta.com, "Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH v6 5/7] locking: Add contended_release tracepoint to qspinlock
Date: Thu, 14 May 2026 14:13:35 +0000 [thread overview]
Message-ID: <agXYjw3GM15WtC-H@shell.ilvokhin.com> (raw)
In-Reply-To: <20260513114102.50f4ca68@gandalf.local.home>
On Wed, May 13, 2026 at 11:41:02AM -0400, Steven Rostedt wrote:
> On Tue, 5 May 2026 17:09:34 +0000
> Dmitry Ilvokhin <d@ilvokhin.com> wrote:
>
> > Use the arch-overridable queued_spin_release(), introduced in the
> > previous commit, to ensure the tracepoint works correctly across all
>
> Remove the ", introduced in the previous commit," That's useless in git
> change logs.
Thanks for the suggestion, will do here and in other places.
[...]
> > /**
> > * queued_spin_unlock - unlock a queued spinlock
> > * @lock : Pointer to queued spinlock structure
> > + *
> > + * Generic tracing wrapper around the arch-overridable
> > + * queued_spin_release().
> > */
> > static __always_inline void queued_spin_unlock(struct qspinlock *lock)
> > {
> > + /*
> > + * Trace and release are combined in queued_spin_release_traced() so
> > + * the compiler does not need to preserve the lock pointer across the
> > + * function call, avoiding callee-saved register save/restore on the
> > + * hot path.
> > + */
> > + if (tracepoint_enabled(contended_release)) {
> > + queued_spin_release_traced(lock);
> > + return;
>
> Get rid of the "return;". What does it save you? It just makes it that you
> need to duplicate the code. Even though it's a one liner, it can cause bugs
> in the future if this changes. You could call the function:
>
> do_trace_queued_spin_release_traced(lock);
>
>
> > + }
> > queued_spin_release(lock);
> > }
> >
> > diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> > index af8d122bb649..649fdca69288 100644
> > --- a/kernel/locking/qspinlock.c
> > +++ b/kernel/locking/qspinlock.c
> > @@ -104,6 +104,14 @@ static __always_inline u32 __pv_wait_head_or_lock(struct qspinlock *lock,
> > #define queued_spin_lock_slowpath native_queued_spin_lock_slowpath
> > #endif
> >
> > +void __lockfunc queued_spin_release_traced(struct qspinlock *lock)
> > +{
> > + if (queued_spin_is_contended(lock))
> > + trace_call__contended_release(lock);
> > + queued_spin_release(lock);
>
> And then remove the duplicate call of "queued_spin_release()" here.
This is the scenario the comment above the static branch describes.
Here's what it looks like in practice on x86_64 (defconfig, compiled
with GCC 11).
Current design (trace + unlock combined, with return):
endbr64
xchg %ax,%ax ; NOP (static branch)
movb $0x0,(%rdi) ; unlock
decl %gs:__preempt_count
je preempt
jmp __x86_return_thunk
call queued_spin_release_traced ; cold
jmp preempt_handling ; cold
call __SCT__preempt_schedule
jmp __x86_return_thunk
With the trace-only function (no return, unlock after the call):
endbr64
push %rbx ; saves callee-saved rbx (!)
mov %rdi,%rbx ; preserve lock across call (!)
xchg %ax,%ax ; NOP (static branch)
movb $0x0,(%rbx) ; unlock
decl %gs:__preempt_count
je preempt
pop %rbx ; callee-saved restore (!)
jmp __x86_return_thunk
call queued_spin_release_traced ; cold
jmp unlock ; cold
call __SCT__preempt_schedule
pop %rbx
jmp __x86_return_thunk
Three extra instructions marked by "!" on the hot path (push, mov, pop),
all wasted when the tracepoint is off. That's the main reason for
combining trace and unlock in the same out-of-line function.
next prev parent reply other threads:[~2026-05-14 14:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 17:09 [PATCH v6 0/7] locking: contended_release tracepoint instrumentation Dmitry Ilvokhin
2026-05-05 17:09 ` [PATCH v6 1/7] tracing/lock: Remove unnecessary linux/sched.h include Dmitry Ilvokhin
2026-05-05 17:09 ` [PATCH v6 2/7] locking/percpu-rwsem: Extract __percpu_up_read() Dmitry Ilvokhin
2026-05-05 17:09 ` [PATCH v6 3/7] locking: Add contended_release tracepoint to sleepable locks Dmitry Ilvokhin
2026-05-05 17:09 ` [PATCH v6 4/7] locking: Factor out queued_spin_release() Dmitry Ilvokhin
2026-05-13 15:37 ` Steven Rostedt
2026-05-05 17:09 ` [PATCH v6 5/7] locking: Add contended_release tracepoint to qspinlock Dmitry Ilvokhin
2026-05-13 15:41 ` Steven Rostedt
2026-05-14 14:13 ` Dmitry Ilvokhin [this message]
2026-05-14 16:03 ` Steven Rostedt
2026-05-13 19:33 ` Peter Zijlstra
2026-05-14 12:34 ` Dmitry Ilvokhin
2026-05-05 17:09 ` [PATCH v6 6/7] locking: Factor out __queued_read_unlock()/__queued_write_unlock() Dmitry Ilvokhin
2026-05-13 15:41 ` Steven Rostedt
2026-05-05 17:09 ` [PATCH v6 7/7] locking: Add contended_release tracepoint to qrwlock Dmitry Ilvokhin
2026-05-13 15:43 ` Steven Rostedt
2026-05-13 19:26 ` [PATCH v6 0/7] locking: contended_release tracepoint instrumentation Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agXYjw3GM15WtC-H@shell.ilvokhin.com \
--to=d@ilvokhin.com \
--cc=ajay.kaher@broadcom.com \
--cc=alexey.makhalov@broadcom.com \
--cc=arnd@arndb.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=boqun@kernel.org \
--cc=bp@alien8.de \
--cc=cl@gentwo.org \
--cc=dave.hansen@linux.intel.com \
--cc=dennis@kernel.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=kernel-team@meta.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
--cc=tj@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=virtualization@lists.linux.dev \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox