All of lore.kernel.org
 help / color / mirror / Atom feed
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.



  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.