On Mon, 9 Mar 2026 20:45:31 +0000
Matthew Wilcox <[email protected]> wrote:
> 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
> [...]
Ah, you're correct. Looks like it's an arch specific thing. I was going
back to my memory from around 2006, but it appears that only a few archs
inline spinlocks anymore. Thomas made it a bit easier to see what does and
does not do that (in 2009).
6beb000923882 ("locking: Make inlining decision Kconfig based")
So, perhaps adding code to the spinlocks will not be as much of a hit on I$.
> (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)
Yeah, I feel like I'm always relearning the code every time I have to jump
in and understand it again.
>
> > 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.
Right.
-- Steve
