From: Matthew Wilcox <willy@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Dmitry Ilvokhin <d@ilvokhin.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@kernel.org>, Len Brown <lenb@kernel.org>,
Brendan Jackman <jackmanb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Oscar Salvador <osalvador@suse.de>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-trace-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v4 0/5] mm: zone lock tracepoint instrumentation
Date: Mon, 9 Mar 2026 20:45:31 +0000 [thread overview]
Message-ID: <aa8xawMxLeUjkyHx@casper.infradead.org> (raw)
In-Reply-To: <20260309151317.7bba06dd@gandalf.local.home>
On Mon, Mar 09, 2026 at 03:13:17PM -0400, Steven Rostedt wrote:
> The biggest issue with making a generic light weight LOCK_STAT is that
> locks are extremely optimized. Any addition of generic lock encoding will
> cause a noticeable overhead when compiled in, even when disabled.
I'm not sure that's true. Taking the current Debian kernel config
leads to a "call" instruction to acquire a spinlock:
void __insert_inode_hash(struct inode *inode, unsigned long hashval)
{
struct hlist_head *b = inode_hashtable + hash(inode->i_sb, hashval);
spin_lock(&inode_hash_lock);
spin_lock(&inode->i_lock);
hlist_add_head_rcu(&inode->i_hash, b);
spin_unlock(&inode->i_lock);
spin_unlock(&inode_hash_lock);
}
compiles to:
[...]
280: 23 35 00 00 00 00 and 0x0(%rip),%esi # 286 <__insert_inode_hash+0x56>
282: R_X86_64_PC32 .data..ro_after_init+0x10
286: 48 8d 2c f0 lea (%rax,%rsi,8),%rbp
28a: e8 00 00 00 00 call 28f <__insert_inode_hash+0x5f>
28b: R_X86_64_PLT32 _raw_spin_lock-0x4
28f: 4c 89 e7 mov %r12,%rdi
292: e8 00 00 00 00 call 297 <__insert_inode_hash+0x67>
293: R_X86_64_PLT32 _raw_spin_lock-0x4
[...]
Debian doesn't do anything too weird here:
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_LOCK_DEBUGGING_SUPPORT=y
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_LOCK_TORTURE_TEST is not set
# CONFIG_WW_MUTEX_SELFTEST is not set
# CONFIG_SCF_TORTURE_TEST is not set
# CONFIG_CSD_LOCK_WAIT_DEBUG is not set
(The spinlock code is too complex for me to follow what config options
influence whether it's a function call; you probably have enough of it
in your head that you'd know)
> The other issue is the data we store for the lock. A lock is usually just a
> word (or long) in size, embedded in a structure. LOCKDEP and LOCK_STAT adds
> a key per lock. This increases the data size of the kernel.
It does, but perhaps for a light weight lockstat, we could do better
than that. For example it could use the return address to look up
which lock is being accessed rather than embedding a key in each lock.
next prev parent reply other threads:[~2026-03-09 20:45 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 16:00 [PATCH v4 0/5] mm: zone lock tracepoint instrumentation Dmitry Ilvokhin
2026-02-27 16:00 ` [PATCH v4 1/5] mm: introduce zone lock wrappers Dmitry Ilvokhin
2026-02-27 20:36 ` David Hildenbrand (Arm)
2026-02-28 1:13 ` Zi Yan
2026-02-28 16:23 ` SeongJae Park
2026-03-02 13:34 ` Vlastimil Babka (SUSE)
2026-02-27 16:00 ` [PATCH v4 2/5] mm: convert zone lock users to wrappers Dmitry Ilvokhin
2026-02-27 20:39 ` David Hildenbrand (Arm)
2026-03-02 15:22 ` Dmitry Ilvokhin
2026-02-28 1:14 ` Zi Yan
2026-03-02 13:42 ` Vlastimil Babka (SUSE)
2026-02-27 16:00 ` [PATCH v4 3/5] mm: convert compaction to zone lock wrappers Dmitry Ilvokhin
2026-02-27 20:39 ` David Hildenbrand (Arm)
2026-02-28 1:16 ` Zi Yan
2026-02-28 16:31 ` SeongJae Park
2026-03-02 14:02 ` Vlastimil Babka (SUSE)
2026-02-27 16:00 ` [PATCH v4 4/5] mm: rename zone->lock to zone->_lock Dmitry Ilvokhin
2026-02-27 20:40 ` David Hildenbrand (Arm)
2026-02-28 1:17 ` Zi Yan
2026-03-02 14:10 ` Vlastimil Babka (SUSE)
2026-03-02 22:37 ` Andrew Morton
2026-03-03 14:25 ` Dmitry Ilvokhin
2026-03-04 1:50 ` SeongJae Park
2026-03-04 13:01 ` Dmitry Ilvokhin
2026-03-04 15:13 ` SeongJae Park
2026-03-04 15:17 ` SeongJae Park
2026-03-05 9:27 ` Vlastimil Babka (SUSE)
2026-03-05 14:55 ` SeongJae Park
2026-03-05 18:16 ` Dmitry Ilvokhin
2026-03-05 18:59 ` Dmitry Ilvokhin
2026-03-06 1:20 ` SeongJae Park
2026-03-06 8:05 ` Vlastimil Babka (SUSE)
2026-03-06 10:30 ` Pedro Falcato
2026-02-27 16:00 ` [PATCH v4 5/5] mm: add tracepoints for zone lock Dmitry Ilvokhin
2026-02-27 19:46 ` Steven Rostedt
2026-03-02 15:18 ` Dmitry Ilvokhin
2026-03-02 14:16 ` Vlastimil Babka (SUSE)
2026-03-09 13:10 ` [PATCH v4 0/5] mm: zone lock tracepoint instrumentation Matthew Wilcox
2026-03-09 14:21 ` Dmitry Ilvokhin
2026-03-09 14:47 ` Matthew Wilcox
2026-03-09 19:13 ` Steven Rostedt
2026-03-09 20:45 ` Matthew Wilcox [this message]
2026-03-09 21:17 ` Steven Rostedt
2026-03-16 17:40 ` Dmitry Ilvokhin
2026-03-19 13:22 ` Dmitry Ilvokhin
2026-03-24 23:39 ` Andrew Morton
2026-03-25 12:14 ` Dmitry Ilvokhin
2026-03-25 14:19 ` Steven Rostedt
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=aa8xawMxLeUjkyHx@casper.infradead.org \
--to=willy@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=d@ilvokhin.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.com \
--cc=ziy@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.