[PATCH] Add ktrace records for user page faults

[John Baldwin]

On Monday, May 02, 2011 3:55:55 pm Kostik Belousov wrote:
> On Mon, May 02, 2011 at 03:37:19PM -0400, John Baldwin wrote:
> > One thing I have found useful is knowing when processes are in the kernel 
> > instead of in userland.  ktrace already provides records for syscall 
> > entry/exit.  The other major source of time spent in the kernel that I've seen 
> > is page fault handling.  To that end, I have a patch that adds ktrace records 
> > to the beginning and end of VM faults.  This gives a pair of records so a user 
> > can see how long a fault took (similar to how one can see how long a syscall 
> > takes now).  Sample output from kdump is below:
> > 
> >  47565 echo     CALL  mmap(0x800a87000,0x179000,PROT_READ|
> > PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
> >  47565 echo     RET   mmap 34370777088/0x800a87000
> >  47565 echo     PFLT  0x800723000 VM_PROT_EXECUTE
> >  47565 echo     RET   KERN_SUCCESS
> >  47565 echo     CALL  munmap(0x800887000,0x179000)
> >  47565 echo     RET   munmap 0
> >  47565 echo     PFLT  0x800a00000 VM_PROT_WRITE
> >  47565 echo     RET   KERN_SUCCESS
> > 
> > The patch is available at www.freebsd.org/~jhb/patches/ktrace_fault.patch and 
> > included below.
> 
> One immediate detail is that trap() truncates the fault address to the
> page address, that arguably looses useful information.

It is true that it would be nice to have the exact faulting address, though
having page granularity has been sufficient for the few times I've actually
used the address itself (e.g. I could figure out which page of libstdc++ a
fault occurred on and narrow down from there as to which of the routines most
likely was executed given what the app was doing at the time).  In my case
knowing how much time was spent handling a page fault has been useful.

Would we have to push this logic out of vm_fault and into every trap() routine
to get the original address?  That would make the patch quite a bit bigger
(touching N MD files vs 1 MI file).

-- 
John Baldwin