In article <[EMAIL PROTECTED]>,
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
>Hi,
>
>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:
linux/mm/filemap.c:
* 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.
Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
