Subject: Re: "out of space kmem_map" panic on sun3x
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Jeremy Cooper <jeremy@baymoo.org>
List: port-sun3
Date: 10/17/2000 09:58:41
On Tue, 17 Oct 2000, Izumi Tsutsui wrote:

> dump_kmemstats() says "VM pmap" wastes kernel memory:
> 
> 34 VM pmap              2516608
> 82 UVM amap             74144
> 62 ttys                 63232
>  2 devbuf               29472
> 28 UFS mount            27664
> 49 Export Host          8192

Izumi, this the most conclusive evidence yet of the source of this bug!  
I think you've got it.  I have no idea why the pmap lock functions are
commented out in the reference tracking functions pmap_reference() and
pmap_dereference()!

I vaguely recall having a conversation with Gordon Ross about pmap locks
and how the sun3x pmap should be designed not to rely on them, at least at
the very lowest levels.  But clearly this is a high level interface
function to the VM system and as such, it's ok (and even necessary) for it
to use locking mechanisms.

Can someone do a test for me and anyone uncomment the 'pmap_lock(pmap);'
and 'pmap_unlock(pmap);' lines that occur in both the sun3x
pmap_reference() and pmap_dereference()?  As usual, a full make build of
the source tree should suffice as a stress test.

Thanks,
Jeremy