On Mon, 9 Mar 2026 14:47:29 +0000 Matthew Wilcox <[email protected]> wrote:
> > CONFIG_LOCK_STAT provides useful statistics, but it is primarily a > > debug facility and is generally too heavyweight for the production > > environments. > > Yes, agreed. I think that is what needs to change. 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. Most of the lock code is inlined for the fast path. Now if we want to add lock stats, we would need to add hooks into those inlined paths. This will undoubtedly increase the size of text, which will have an impact on I$. 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. LOCK_STAT was designed on top of LOCKDEP. Perhaps a lighter version of LOCK_STAT could be designed without LOCKDEP, but it would be a project on its own. -- Steve
