From: Jan Polensky <japo@linux.ibm.com>
To: hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com
Cc: borntraeger@linux.ibm.com, svens@linux.ibm.com,
ciunas@linux.ibm.com, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2] s390/rwlock: Add contention tracepoints to rwlock slowpath
Date: Tue, 8 Sep 2026 15:58:43 +0200 [thread overview]
Message-ID: <20260908135843.1384367-1-japo@linux.ibm.com> (raw)
Instrument arch_read_lock_wait() and arch_write_lock_wait() with
trace_contention_begin() and trace_contention_end().
These tracepoints are used by lock contention analysis tools such as
perf lock contention to identify contended rwlocks and measure wait
times. The generic implementation in kernel/locking/qrwlock.c already
emits the same events from its read and write slowpaths.
For arch_read_lock_wait(), the in_interrupt() fast-path is intentionally
left outside the tracepoint scope. That path spins without entering the
wait queue, so it does not represent queue-based contention and its
duration is not comparable to the normal slowpath. This matches the
behaviour of queued_read_lock_slowpath() in qrwlock.c.
The include for <trace/events/lock.h> is already present from
commit ffa796cc1f45 ("s390/spinlock: Add contention tracepoints to
lock slowpath").
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
v1 -> v2:
- Fix tracepoint placement in arch_read_lock_wait() to avoid recursion deadlocks.
arch/s390/lib/spinlock.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/s390/lib/spinlock.c b/arch/s390/lib/spinlock.c
index dbabca35c008..c84991a1be20 100644
--- a/arch/s390/lib/spinlock.c
+++ b/arch/s390/lib/spinlock.c
@@ -318,6 +318,7 @@ void arch_read_lock_wait(arch_rwlock_t *rw)
/* Remove this reader again to allow recursive read locking */
__atomic_add_const(-1, &rw->cnts);
+ trace_contention_begin(rw, LCB_F_SPIN | LCB_F_READ);
/* Put the reader into the wait queue */
arch_spin_lock(&rw->wait);
/* Now add this reader to the count value again */
@@ -326,6 +327,7 @@ void arch_read_lock_wait(arch_rwlock_t *rw)
while (READ_ONCE(rw->cnts) & 0x10000)
barrier();
arch_spin_unlock(&rw->wait);
+ trace_contention_end(rw, 0);
}
EXPORT_SYMBOL(arch_read_lock_wait);
@@ -333,6 +335,7 @@ void arch_write_lock_wait(arch_rwlock_t *rw)
{
int old;
+ trace_contention_begin(rw, LCB_F_SPIN | LCB_F_WRITE);
/* Add this CPU to the write waiters */
__atomic_add(0x20000, &rw->cnts);
@@ -349,6 +352,7 @@ void arch_write_lock_wait(arch_rwlock_t *rw)
}
arch_spin_unlock(&rw->wait);
+ trace_contention_end(rw, 0);
}
EXPORT_SYMBOL(arch_write_lock_wait);
--
2.53.0
reply other threads:[~2026-09-08 13:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260908135843.1384367-1-japo@linux.ibm.com \
--to=japo@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=ciunas@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=svens@linux.ibm.com \
/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
all inboxes | Powered by JetHome®