Thanks for the response.

> Date: Sun, 4 Dec 1994 10:50:14 -0800
> From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
> 
> I believe not only is this change not going to buy much -- it's
> at best simply shifting the time that the price is paid, possibly 
> saving some cost by having more state around when the price *is*
> paid, possibly paying that smaller cost more often -- but there
> are cases where it could  significantly hurt.
> 
> The real issue is assuming that if a page incurs an MMU
> capacity miss, that makes it a candidate for pageout.
> (I assume that's what deactivating does.)

Yes, that is the issue.  Also, note that "deactivating" a page
(putting it on the inactive list) does not immediately force it
to be paged-out; it only makes it a candidate for pageout. The
actual pageout only happens if it the page stays on the inactive
list long enough for the pageout daemon to get to it.

> Let's say we've got a  Sun3 architecture machine (i.e., not
> a Sun3/80)  that's thrashing its pmegs.  Suppose further
> that the machine also has _almost_ enough phyiscal memory to hold the
> pages that are in its working set -- i.e., the machine is thrashing
> its Sun MMU entries but not pageframes.  The machine is paging
> some, but not  heavily.
> 
> In such a scenario, wouldn't this change make the machine thrash?
> Those pages that incur a pmeg miss but are still active will be
> transferred between physical memory and disk?  [...]

I don't think so, because deactivating pages does not necessarily
mean they will be paged out.  The pageout daemon walks the inactive
list and first checks/clears the reference bit; if the page was
referenced it is moved back to the active list.  Otherwise, the
page is cleaned (if necesary) and will eventually be reassigned.

When removing a mapping due to MMU capacity, I could deactive only
pages that were not referenced, though that would mean doing work
that could be delayed until the pageout deamon runs.  If I go ahead
and deactive all the pages being unmapped, the pageout daemon will
ask the pmap if the pages are referenced, and if so, clear the
reference bits and move them back to the active list.

I think deactivating at least unreferenced pages should result in
the best physical page allocation, but I'm not sure.  I have not
seen any other pmap designs that deal with a capacity-limited MMU.

Gordon