On Mon, Dec 02, 2024 at 02:35:22PM +0000, Stuart Henderson wrote:
> On 2024/12/02 15:12, Claudio Jeker wrote:
> > On Mon, Dec 02, 2024 at 01:53:02PM +0000, Stuart Henderson wrote:
> > > Thought I'd take a look at a kernel profile from a machine which is
> > > fairly "interesting" in terms of kernel spin. (Running -current).
> > > 
> > > In the attached output from running "btrace kprofile.bt" I have a
> > > lot of time accounted for under syscall+0x5c4, which has _kernel_lock
> > > directly next to it in the traces, and I was wondering what that is.
> > > Bit confused by disasm of trap.o but my guess is that it might be
> > > a lock relating to dt(4) itself, is that right?
> >  
> > I think this is the bit of syscall that grabs the kernel lock for any
> > syscall not marked NOLOCK. In your case this is mostly fstat*, open*
> > or the bits under syscall+0x5e7.
> 
> Thank you.
> 
> > Your system does a lot of parallel disk IO and that is all still using the
> > KERNEL_LOCK.
> 
> oh, I should try "VFS syscalls & KERNEL_LOCK()" on this machine!

Right now you are mostly out of luck. All vfs operations you do require
the KERNEL_LOCK at some point. The win by moving this a few functions down
is very little.  Just look at how bad close and vn_closefile are.

-- 
:wq Claudio