Subject: Re: vm_fault in pmap_changebit()
To: Dave Huang <khym@bga.com>
From: Chuck Cranor <chuck@maria.wustl.edu>
List: port-i386
Date: 11/13/1997 09:32:17
>Thanks for the explanation :) Ah well... I don't know enough to debug this
>problem... Might it be somehow related to the "lockmgr: locking against
>myself" panics? I haven't been getting those anymore, but I'm now getting
>these vm_faults.

it isn't directly related to that, but there could be an indirect
relationship.  i think it might be a bit harder to debug this because 
the user's page table pages are part of user VM and are added by 
faulting them in using the general VM code.  one thing you might do
is keep a list of all active pmaps on the system and then when you
get the error see if the pmap that is in the bad pv entry is on
that list or not.   then you would better know if the problem was a 
stale pv_entry or a missing page table page.


>Cool... are there are there any plans to replace the current VM system
>with yours?

it is being looked at.  basically, i have made the code available
and structured the code in such a way that both the old VM system 
and my VM system can live in a kernel source tree at the at the 
same time (thus making the choice of VM system a compile time option
since i can't see just replacing the old VM without transition period).
given my current workload (and my need to graduate) that's about all 
i have time to do right now.


the status of my current code is that does everything the -current code 
does with the exception of:
 [1] async pageout to swap -- it does sync pageout, the async code
        is written but has not been debugged.
 [2] SYSV shared memory
 [3] swapping (i.e. making the u-area pageout to swap)
 [4] libkvm programs don't work (since i've changed all the internal
        VM data structures)

[2] and [3] require a new pager for vm_objects backed by anonymous
memory to be written (something i have a draft design for but am
not working on now).   currently anonymous memory is only handled
through "anon" structures (sort of as described in the SunOS VM 
paper).  note that there are no vm_object shadow/copy chains in my 
code (and thus no "object collapse" code to cause headaches like 
the lockmgr panic problem).

the code runs on sparc and i386 (use it all the time on my home
i386 workstation).   the only thing preventing it from running on 
other ports is that i rewrote MACHINE_NONCONTIG support (yielding
MACHINE_NEW_NONCONTIG -- a.k.a. MNN) and the other ports haven't 
been converted to MNN yet (MNN run with either VM system, but my 
VM system currently requires it).

chuck