hi,

On Fri, Feb 04, 2005 at 01:10:38PM -0800, John Klos wrote:
> Hello,
> 
> More experimentation. Even when I custom compile a kernel with nkmempages 
> set to 4224 (on a mac68k system with 132 megs of memory, 4k pages), which 
> should limit the kernel to about 33 megs in size, I see it grow to upwards 
> of 70 megs (it's at 67 at the moment). On a system with 36 megs of memory, 
> the kernel's usage as reported by top is 36 megs; if I leave it, it will 
> crash in a few hours.
> 
> Would anyone be willing to help me figure out what's going on? I'd love to 
> see 2.0 be usable on Amigas and on m68k Macs, and perhaps other m68k 
> machines.

oh, from your mail about this on wednesday I thought you were saying the
problem wasn't happening anymore.  I'm happy to help with this.

after one of your earlier reports of the problem, I tried to reproduce it
on a quadra 650, but everything was normal for me.

since the leaked memory doesn't show up in "vmstat -m", that means that
it's being allocated via some lower-level interface than malloc() or
pool_get().  my current guess is the pmap code itself, and you could
check on that by adding some counters next to the uvm_page{alloc,free}
calls in pmap_motorola.c (or pmap.c on amiga).


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.

 (2) add a bit of code to uvm_page{alloc,free}() that keeps a histogram of
     the return addresses.  when the machine hangs, dump out all the counters
     and see what doesn't match up.

I can help with analyzing the reams of data that would be produced
by either of these techniques.

-Chuck