Re: O_STREAMING has insufficient info - how about fadvise() ?

From: Oliver Xymoron <oxymoron@waste.org>
To: Andrew Morton <akpm@digeo.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	andersen@codepoet.org, Jamie Lokier <lk@tantalophile.demon.co.uk>,
	Mark Mielke <mark@mark.mielke.cc>,
	Giuliano Pochini <pochini@denise.shiny.it>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: O_STREAMING has insufficient info - how about fadvise() ?
Date: Thu, 10 Oct 2002 11:49:17 -0500	[thread overview]
Message-ID: <20021010164916.GO21400@waste.org> (raw)
In-Reply-To: <3DA59DED.6167C13B@digeo.com>

On Thu, Oct 10, 2002 at 08:34:05AM -0700, Andrew Morton wrote:
> 
> dropbehind cannot work as effectively because we're basically forced
> to put the pages at the head of the inactive LRU and hope that they're
> written before they reach the tail.  By which time we've evicted
> all the other pagecache on the inactive list.

Seems like we're not keeping enough information. Perhaps we could have
something like "streaming rank" at the mapping level and use that as a
hint to prioritize evictions or possibly where to insert in the LRU.
Throw new mappings at the streaming end of the rank list and whenever
they fault behind the r/w pointer, swap them upwards in the list.

If you're playing an MP3, it starts out at the streaming end of the
list and starts dropping pages at the first sign of pressure. Since
this really is streaming, no problem.

Now run Mozilla, which starts out behind the MP3, seeks around
randomly paging in code (which looks like fault behind), says "um,
excused me", and bumps ahead of the MP3..

Let Mozilla idle, start OpenOffice, which bumps in front of the MP3,
and if it hits more pressure, bumps in front of the idling Mozilla as
well.

Then updatedb starts, reads a ton of files in a streaming fashion, but
none of those streaming file mappings push above the idling apps.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 