Messages in this thread |  | | From | (Miquel van Smoorenburg) | Subject | Re: O_DIRECT! or O_DIRECT? | Date | Wed, 4 Jul 2001 20:23:10 +0000 (UTC) |
| |
In article <20010704193402.A6403@redhat.com>, Stephen C. Tweedie <sct@redhat.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |