Subject: Re: UBC status
To: Chuck Silvers <firstname.lastname@example.org>
From: Eduardo E. Horvath <email@example.com>
Date: 09/30/1999 09:59:02
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:
> 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 firstname.lastname@example.org
"I need to find a pithy new quote." -- me