On Fri, Feb 04, 2005 at 08:10:29PM -0700, Michael L. Hitch wrote:
> > if that's not it, other things to try would be:
> >
> >  (1) with the machine in the fully-leaked state, print out all the vm_page
> >      structures and look at the uobject, uoffset and uanon fields and see if
> >      there's any pattern to them.  pretty much all of them would have been
> >      leaked by the time the machine wedges up.  you could write a little
> >      C function to call from ddb and just print all the info to the serial
> >      console.
> 
>   Is this similar to the info that pmap(1) can print?
> 
> amiga$ pmap -v -p0 -a
> Start    End         Size  Offset   rwxpc  RWX  I/W/A Dev     Inode - File
> 00000000-004affff    4800k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ stack ]
> 004b0000-0052dfff     504k 004b0000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 0052e000-0252dfff   32768k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ kmem_map ]
> 0252e000-0352dfff   16384k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ pager_map ]
> 0352e000-03597fff     424k 0352e000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 03598000-03997fff    4096k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ exec_map ]
> 03998000-04997fff   16384k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ phys_map ]
> 04998000-04a17fff     512k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ mb_map ]
> 04a18000-04a8ffff     480k 04a18000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 04a90000-0528ffff    8192k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ ubc_pager ]
> 05290000-05869fff    5992k 05290000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 0586e000-058d1fff     400k 0586e000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 058d4000-058fffff     176k 058d4000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 05902000-05903fff       8k 05902000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 05908000-0590bfff      16k 05908000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 05916000-0591bfff      24k 05916000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 0591e000-05921fff      16k 0591e000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 05926000-05929fff      16k 05926000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 0592e000-05931fff      16k 0592e000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 05934000-0649ffff   11696k 05934000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 064a2000-064a3fff       8k 064a2000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 064a8000-064abfff      16k 064a8000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 064ae000-07827fff   19944k 064ae000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 07830000-0784ffff     128k 07830000 rwxs- (rwx) 2/0/1 00:00       0 -   [ uvm_aobj ]
> 089ba000-091fffff    8472k 00000000 ---s- (---) 2/0/1 00:00       0 -   [ anon ]
> 20000000-2102ffff   16576k 00000000 rwxs- (rwx) 2/0/1 00:00       0 -   [ pt_map ]
>  total             139576k
> amiga$ ps up0
> USER PID %CPU %MEM VSZ   RSS TT STAT STARTED    TIME COMMAND
> root   0  0.0 38.7   0 50656 ?? DKs  11:26PM 0:00.48 [swapper]


hmm, I was looking at the m68k-common pmap, which is a little different.
amiga uses the top-level kernel_map instead of having an st_map submap,
which muddies the waters a bit.  the leak has to be those huge uvm_aobj
mappings, but we don't know what they are.  we'll probably need to do
the histogram of the callers of uvm_page{alloc,free}.

-Chuck