At 02:39 PM 2/26/2004, Daniel Carosone wrote:
>On Thu, Feb 26, 2004 at 01:23:26PM -0800, Jason Thorpe wrote:
> > This actually implements the
> > two-handed-clock algorithm the way I think was intended:
> >
> >       1. Active pages are scanned.  Pages that have not been referenced
> >          since the last active scan are moved to the inactive queue.
> >
> >       2. Inactive pages are scanned.  Pages that have been referenced
> >          since being put on the inactive queue are moved back to the
> >          active queue.  Otherwise, the page is cleaned / freed.
> >
> > The idea is that this finds your working set and keeps it in core.
>
>Sound idea, and probably worth keeping.
>
> > Basically, if you have some VERY ACTIVE files that consume nearly
> > all physical memory, those pages will always be reactivated.  [and
> > thus not be considered for removal even if they're above the high
> > water mark for that page type]
>
> > Does anyone have any thoughts on how to fix this problem?  I'm inclined
> > to kill the reactivation path completely, but I would prefer reactivate
> > an actually active page of a certain type than an inactive one.
>
>If you kill the reactivation path completely, you may end up evicting
>a should-be-active page over one that's really stale.  And perhaps
>even doing that again when you need to page it back in again shortly
>after.

It seems to me that you can only reactivate a file/exec/anon page when
that class of active pages is below their max setting.  If it grows above
then inactive pages will be reaped until only the most active pages are
retained.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.