Re: [RFC] Optimization for use-once pages

From: Daniel Phillips (
Date: Tue Jul 24 2001 - 19:04:30 EST

On Tuesday 24 July 2001 18:56, Rik van Riel wrote:
> On Tue, 24 Jul 2001 wrote:
> > On Tue, Jul 24, 2001 at 05:47:30AM +0200, Daniel Phillips wrote:
> > > So I decided to look for a new way of approaching the use-once
> > > problem that would easily integrated with our current approach.
> > > What I came up with is pretty simple: instead of starting a newly
> > > allocated page on the active ring, I start it on the inactive
> > > queue with an age of zero. Then, any time generic_file_read or
> > > write references a page, if its age is zero, set its age to
> > > START_AGE and mark it as unreferenced.
> >
> > This is wonderfully simple and ellegant.
> It's a tad incorrect, though.
> If a page gets 2 1-byte reads in a microsecond, with this
> patch it would get promoted to the active list, even though
> it's really only used once.

Yes, I expected that to be a relatively rare case however - block
aligned transfers are much more common, and when we have multiple
blocks per page we may well want the page to go onto the active list
because there may be quite a delay between successive block accesses.
>From there it will be aged normally, not such a horrible thing.

To fix this properly I suspect that just a few microseconds is enough
delay to pick up the temporal groupings you're talking about. That's
not hard to achieve.

> Preferably we'd want to have a "new" list of, say, 5% maximum
> of RAM size, where all references to a page are ignored. Any
> references made after the page falls off that list would be
> counted for page replacement purposes.

At that size you'd run a real risk of missing the tell-tale multiple
references that mark a page as frequently used. Think about metadata
here (right now, that usually just means directory pages, but later...
who knows). Once somebody has looked at two files in a directory -
while the page sits on the "ignore" list - chances are very good
they'll look at a third, but perhaps not before it drops off the south
end of the inactive queue.

Well, theorizing can only get us so far before we need to take actual

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:20 EST