Re: wired memory leak?

[Greg Troxel <gdt%lexort.com@localhost>]

Taylor has been helping me with dtrace off list, and I've been
experimenting.   It feels like huge progress, but not there yet.

First, I see about 4000 pages of wired memory increase from running
glxgears -fullscreen once.  However it's not that simple.  I'm logging
the value (from vmstat) every second.  It jumps up, and then drops at
exit, and bounces around.   But, there is a pronounced floor of the
bouncing, and the before-floor is about 4K pages less than the
after-floor.


My current dtrace setup is to run a shell script that sleeps for 60s,
runs glxgear -fullscreen (until I hit escape) and then sleep for 60s, to
try to capture the freeing that happens in the short time after exit;
the X server hanging onto memory for a few seconds and freeing it, if
that's what happens, would not be a real bug.

  #!/bin/sh

  echo "STAMP $(date +%s)"

  dtrace -c ./_glx -n '
          fbt::kmem_intr_alloc:entry { @alloc["alloc", arg0, stack()] = count() }
          fbt::kmem_intr_free:entry { @free["free", arg1, stack()] = count() }
          fbt::uvm_km_alloc:entry { @alloc["alloc_u", arg1, stack()] = count() }
          fbt::uvm_km_free:entry { @free["free_u", arg2, stack()] = count() }
  '

  echo "STAMP $(date +%s)"

With this, there are smallish leaks that amount to 100K from
kmem_intr_alloc.  Perhaps real, perhaps not, but not the Big Problem.
(They could have pointers to leaked bigger things.)

The uvm_km_alloc lines show two allocations and matching frees.

This particular run resulted in a new wired floor that is 4053 pages
higher than the previous floor.

What about kmem_alloc()?  That doesn't seem to be a valid probe.

How else can wired memory be allocated?
<