Subject: Re: hmm2
To: Chuck Cranor , matthew green <firstname.lastname@example.org>
From: Michael L. Hitch <email@example.com>
Date: 05/25/1998 13:14:55
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: firstname.lastname@example.org (Michael L. Hitch)
> >To: email@example.com
> >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
Another case where subtle differences in the VM implementation
causes problems :-)
Michael L. Hitch firstname.lastname@example.org
Information Technology Center
Montana State University Bozeman, MT USA