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

[Andrew Morton <akpm@digeo.com>]

Alan Cox wrote:
> 
> ...
> Instead of O_STREAMING therefore I'd much prefer to have
> 
>         fadvise(filehandle, offset, length, FADV_DONTNEED);

fadvise would make some sense - nice that it's a standardised interface.

It isn't really implementable in 2.4, because of that "offset, length"
thing.  We either have to do a pagecache probe for each page, which
gets painful if the user asked for 10,000,000 pages or we do a
pagelist walk which is painful if the user asked for one page.

In 2.5, the radix tree gang lookup thing will do this search in O(zilch).

The other problem with fadvise is writebehind - there are up to
30 seconds' worth of dirty pages behind the application's write
cursor which fadvise wouldn't be able to do anything with.  So
the application would end up running fadvise(offset=0, length=current-pos)
all the time.   Which is equivalent to O_STREAMING.
 

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.

Could put the pages at the _tail_ of the LRU for reads; but that's
equivalent to just reclaiming them on the spot.  Which is equivalent
to O_STREAMING.