On Wed, 29 Sep 1999, Chuck Silvers wrote:

> ok, I think all of this can be summarized as:
> 
> (1)  trickle-sync is a good thing.
> (2)  it'd be nice to have more differentiation between different kinds of pages,
>      to allow different policies on flushing and reuse.
> 
> the implementation of (1) will be somewhat different for page-cache data
> than it is for buffer-cache data (ie. in the softupdate code), but this
> may be possible to do for the first release with UBC.  y'all can chew on
> this one.  the main rule to keep in mind is that you're not allowed to
> add anything to struct vm_page.

I think I read somewhere (I can't remember where) that some OS syncs the
buffers by traversing a fraction of inodes in the system every few
secondes and flushes them rather than traversing pages.  How difficult
would it be to impment that?

> for (2), soda pointed me to this URL:
> 	http://www.sun.com/sun-on-net/performance/priority_paging.html
> which describes something Sun is working on.  I've been thinking about
> similar stuff for a while, and I'll post my ideas once they've solidified
> a bit more.  or if someone else has some firm ideas already, post away.

Interesting....  I think that Sun is still having problems with the
2-handed clock algorithm they use for page scanning.  We may be able to
get a similar effect by adding a separate active or inactive list for
buffer cache pages.

<Silly idea mode>

What if we always keep buffer-cache pages on the inactive list (unless
dirty, I suppose).  If they are accessed, move them to the end of the
list, but don't migrate them to the active list.  Then buffer cache pages
would have a higher rate of re-use than other pages.

</Silly idea mode>

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me