From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: btrace, identifying syscall+0x5c4
To: tech <tech@openbsd.org>
Cc: Martin Pieuchot <mpi@openbsd.org>
Date: Mon, 2 Dec 2024 14:49:54 +0000

On 2024/12/02 14:35, 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!

...and fwiw that looks like this: