From: Steven Rostedt <rostedt@goodmis.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Dmitry Ilvokhin <d@ilvokhin.com>,
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
Subject: Re: [PATCH v4 0/5] locking: contended_release tracepoint instrumentation
Date: Thu, 26 Mar 2026 12:46:54 -0400 [thread overview]
Message-ID: <20260326124654.66b4dbc1@gandalf.local.home> (raw)
In-Reply-To: <acVW6eFGwqACD91Y@casper.infradead.org>
On Thu, 26 Mar 2026 15:55:21 +0000
Matthew Wilcox <willy@infradead.org> wrote:
> > - The holder's stack at release time, which may differ from what perf lock
> > contention --lock-owner captures if the holder does significant work between
> > the waiter's arrival and the unlock.
>
> As someone who's not an expert in this area (so please use short words
> to explain it to me), why do we want to know how long this holder took
> to release the lock from when it became contended?
>
> I understand why we want to know how long any given waiter had to wait
> to gain the lock (but we already have tracepoints which show that).
>
> I also don't understand why we want to know the holder's stack at
> release time. The stack at contention-begin time will include
> the point at which the lock was acquired which should be correlated
> with where the lock was released.
>
> Perhaps examples might help me understand why we want this?
Dmitry could give his own rationale for this, but I have my only use case.
This would be useful to find out how long the critical section is. If a
lock is highly contended by many tasks, you could get a high contention
time simply because other tasks are causing the delay for the waiter.
Seeing the release time and location would let you also know how long the
critical section was held, and if the length of the critical section is
causing the contention.
Having a stack trace of the release would differentiate the path that
released the lock, as there can be many places that release them. Although,
I have to admit, I'm not sure there are many different places locks are
released. Especially now that we have guard(), which will make all the
releases in a function at the same location.
-- Steve
next prev parent reply other threads:[~2026-03-26 16:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 15:09 Dmitry Ilvokhin
2026-03-26 15:10 ` [PATCH v4 1/5] tracing/lock: Remove unnecessary linux/sched.h include Dmitry Ilvokhin
2026-03-31 10:11 ` Usama Arif
2026-03-26 15:10 ` [PATCH v4 2/5] locking/percpu-rwsem: Extract __percpu_up_read() Dmitry Ilvokhin
2026-03-26 15:10 ` [PATCH v4 3/5] locking: Add contended_release tracepoint to sleepable locks Dmitry Ilvokhin
2026-03-31 10:34 ` Usama Arif
2026-03-31 12:16 ` Dmitry Ilvokhin
2026-03-31 14:11 ` Usama Arif
2026-03-26 15:10 ` [PATCH v4 4/5] locking: Factor out queued_spin_release() Dmitry Ilvokhin
2026-03-26 15:10 ` [PATCH v4 5/5] locking: Add contended_release tracepoint to spinning locks Dmitry Ilvokhin
2026-03-26 15:55 ` [PATCH v4 0/5] locking: contended_release tracepoint instrumentation Matthew Wilcox
2026-03-26 16:46 ` Steven Rostedt [this message]
2026-03-26 17:47 ` Dmitry Ilvokhin
2026-03-31 10:27 ` Usama Arif
2026-03-31 12:32 ` Dmitry Ilvokhin
2026-04-07 13:10 ` Dmitry Ilvokhin
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=20260326124654.66b4dbc1@gandalf.local.home \
--to=rostedt@goodmis.org \
--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=d@ilvokhin.com \
--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=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=tj@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=virtualization@lists.linux.dev \
--cc=will@kernel.org \
--cc=willy@infradead.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