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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:37 EST