On May 25,  8:55am, Chuck Cranor wrote:
> i'm not on port-mips, but this got forwarded.
> 
> In your letter dated Mon, 25 May 1998 16:11:48 +1000, you wrote:
> >From: mhitch@lightning.oscs.montana.edu (Michael L. Hitch)
> >To: port-mips@netbsd.org
> >Subject: UVM on MIPS problems (still!)
> 
> >  Putting some debugging output in uvn_put(), I found that
> >uvn_put() was getting called quite a few times on numerous
> >files.  I wouldn't think uvn_put() should get called like that.
> >It would appear that for some reason, the pages are not
> >being marked clean when they should be.  [That may very well
> >due to something in pmap.c though.]
> 
> actually, it is the other way round... pages start off PG_CLEAN
> and are marked dirty if pmap_is_modified() returns TRUE.  thus,
> you should check pmap_is_modified() which is used to set/clean
> PG_CLEAN on the pages [PG_CLEAN gets set/cleared when pages are
> deactivated].   if you look at uvm_pdaemon.c:
...
> it looks like pmap_is_modified is returning a false positive result causing
> a large number of inactive pages to be !PG_CLEAN?

  Ah, I think I see what is going on.

  The MIPS pmap emulates the "page modified" status by making the TLB
entry read-only for a writeable page that has the PG_CLEAN flag set.  An
exception occurs when trying to write to that page, and the trap handler
will clear the PG_CLEAN flag and update the TLB to be writeable.

  The problem with UVM appears to be that when a text page is being
paged in, it is being entered into the pmap with VM_PROT_DEFAULT
(which includes VM_PROT_WRITE) at a kernel VA.  A "writeable" page
in the kernel VA space is unconditionally marked "dirty" (!PG_CLEAN).
The Mach VM must be handling a pagein from an executable binary
somewhat differently (either it's not being entered initially as
writeable, or the PG_CLEAN bit is explicitly getting set after
pmap_enter() is called).  [A quick glance through vm_fault() seems
to indicate the latter - after the pager gets the page, the PG_CLEAN
flag is explicitly set, and pmap_clear_modify() is also explicitly
called.]

  Another case where subtle differences in the VM implementation
causes problems :-)

Michael

-- 
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA