From: Claudio Jeker Subject: Re: btrace, identifying syscall+0x5c4 To: tech Date: Mon, 2 Dec 2024 15:48:48 +0100 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