From: Miquel van Smoorenburg (
Date: Wed Jul 04 2001 - 15:23:10 EST

In article <>,
Stephen C. Tweedie <> wrote:
>On Wed, Jul 04, 2001 at 06:27:13PM +0000, Miquel van Smoorenburg wrote:
>> Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL))
>What for? The kernel already optimises readahead and writebehind for
>sequential files.

Yes, but I really do mean like in madvise().

>If you want to provide specific extra hints to the kernel, then things
>like O_UNCACHE might be more appropriate to instruct the kernel to
>explicitly remove the cached page after IO completes (to avoid the VM
>overhead of maintaining useless cache). That would provide a definite
>improvement over normal IO for large multimedia-style files or for
>huge copies. But what part of the normal handling of sequential files
>would O_SEQUENTIAL change? Good handling of sequential files should
>be the default, not an explicitly-requested feature.

exactly what I meant, since that is what MADV_SEQUENTIAL seems to do:


 * MADV_SEQUENTIAL - pages in the given range will probably be accessed
 * once, so they can be aggressively read ahead, and
 * can be freed soon after they are accessed.

 * Read-ahead and flush behind for MADV_SEQUENTIAL areas. Since we are
 * sure this is sequential access, we don't need a flexible read-ahead
 * window size -- we can always use a large fixed size window.
static void nopage_sequential_readahead(struct vm_area_struct * vma,

O_SEQUENTIAL perhaps is the wrong name.

I'd like to see this so I can run tar to backup a machine during the
day (if tar used this flag, ofcourse) without performance going
down the drain because of cache pollution.


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 : Sat Jul 07 2001 - 21:00:14 EST