nI 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.)

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'm assuming the
pageframe pool and number of active processes is bigger than the
number of hardware mappings, a good assumption on sun-3s.) I don't
think this is a good tradeoff.

It seems exactly analagous to tying page residency to TLB residency,
which I know isn't right. (Yes, having a page in a TLB entry pins
it, but just because it doesn't fit is no reason to evict the
page from memory.)

I have a much fresher grasp of the details of the paging mechanisms of
a couple of research kernels from Stanford, which I had a hand in
implementing.  I hope I havent' made any egrerious assumptions here.