This fixes inefficient page-by-page reads on POSIX_FADV_RANDOM. POSIX_FADV_RANDOM used to set ra_pages=0, which leads to poor performance: a 16K read will be carried out in 4 _sync_ 1-page reads. In other places, ra_pages==0 means - it's ramfs/tmpfs/hugetlbfs/sysfs/configfs - some IO error happened where multi-page read IO won't help or should be avoided. POSIX_FADV_RANDOM actually want a different semantics: to disable the *heuristic* readahead algorithm, and to use a dumb one which faithfully submit read IO for whatever application requests. So introduce a flag FMODE_RANDOM for POSIX_FADV_RANDOM. Note that the random hint is not likely to help random reads performance noticeably. And it may be too permissive on huge request size (its IO size is not limited by read_ahead_kb). In Quentin's report (http://lkml.org/lkml/2009/12/24/145), the overall (NFS read) performance of the application increased by 313%! v6: use FMODE_RANDOM (proposed by Christoph Hellwig) v5: use bit 0200000000; explicitly nuke the O_RANDOM bit in __dentry_open() (Stephen Rothwell) v4: resolve bit conflicts with sparc and parisc; use bit 040000000(=FMODE_NONOTIFY), which will be masked out by __dentry_open(), so that open(O_RANDOM) is disabled (Stephen Rothwell and Christoph Hellwig) v3: use O_RANDOM to indicate both read/write access pattern as in posix_fadvise(), although it only takes effect for read() now (proposed by Quentin) v2: use O_RANDOM_READ to avoid race conditions (pointed out by Andi) CC: Nick Piggin CC: Andi Kleen CC: Steven Whitehouse CC: David Howells CC: Al Viro CC: Jonathan Corbet CC: Christoph Hellwig Tested-by: Quentin Barnes Signed-off-by: Wu Fengguang --- include/linux/fs.h | 3 +++ mm/fadvise.c | 10 +++++++++- mm/readahead.c | 6 ++++++ 3 files changed, 18 insertions(+), 1 deletion(-) --- linux.orig/mm/fadvise.c 2010-01-09 11:00:11.000000000 +0800 +++ linux/mm/fadvise.c 2010-01-09 12:25:01.000000000 +0800 @@ -77,12 +77,20 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, lof switch (advice) { case POSIX_FADV_NORMAL: file->f_ra.ra_pages = bdi->ra_pages; + spin_lock(&file->f_lock); + file->f_flags &= ~FMODE_RANDOM; + spin_unlock(&file->f_lock); break; case POSIX_FADV_RANDOM: - file->f_ra.ra_pages = 0; + spin_lock(&file->f_lock); + file->f_flags |= FMODE_RANDOM; + spin_unlock(&file->f_lock); break; case POSIX_FADV_SEQUENTIAL: file->f_ra.ra_pages = bdi->ra_pages * 2; + spin_lock(&file->f_lock); + file->f_flags &= ~FMODE_RANDOM; + spin_unlock(&file->f_lock); break; case POSIX_FADV_WILLNEED: if (!mapping->a_ops->readpage) { --- linux.orig/mm/readahead.c 2010-01-09 11:00:11.000000000 +0800 +++ linux/mm/readahead.c 2010-01-09 12:25:01.000000000 +0800 @@ -501,6 +501,12 @@ void page_cache_sync_readahead(struct ad if (!ra->ra_pages) return; + /* be dumb */ + if (filp->f_mode & FMODE_RANDOM) { + force_page_cache_readahead(mapping, filp, offset, req_size); + return; + } + /* do read-ahead */ ondemand_readahead(mapping, ra, filp, false, offset, req_size); } --- linux.orig/include/linux/fs.h 2010-01-09 11:00:29.000000000 +0800 +++ linux/include/linux/fs.h 2010-01-09 12:26:33.000000000 +0800 @@ -90,6 +90,9 @@ struct inodes_stat_t { /* File was opened by fanotify and shouldn't generate fanotify events */ #define FMODE_NONOTIFY ((__force fmode_t)0x1000000) +/* Expect random access pattern */ +#define FMODE_RANDOM ((__force fmode_t)0x1000) + /* * The below are the various read and write types that we support. Some of * them include behavioral modifiers that send information down to the -- 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/