[PATCH] readahead even for FMODE_RANDOM
in [Kernel]
|
Prev: regulator: add support for Dallas DS1803 dual digital potentiometer
Next: oom: fix the unsafe usage of badness() in proc_oom_score()
From: Jens Axboe on 1 Apr 2010 14:40 Hi, I got a problem report with fio where larger block size random reads where markedly slower with buffered IO than with O_DIRECT, and the initial thought was that perhaps this was some fio oddity. The reporter eventually discovered that turning off the fadvise hint made it work fine. So I took a look, and it seems we never do readahead for FMODE_RANDOM even if the request size is larger than 1 page. That seems like a bug, if an application is doing eg 16kb random reads, you want to readahead the 12kb remaining data. On devices where smaller transfer sizes are slower than larger ones, this can make a large difference. This patch makes us readahead even for FMODE_RANDOM, iff we'll be reading more pages in that single read. I ran a quick test here, and it appears to fix the problem (no difference with fadvise POSIX_FADV_RANDOM being passed in or not). Signed-off-by: Jens Axboe <jens.axboe(a)oracle.com> diff --git a/mm/readahead.c b/mm/readahead.c index 337b20e..d4b201c 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -501,8 +501,11 @@ void page_cache_sync_readahead(struct address_space *mapping, if (!ra->ra_pages) return; - /* be dumb */ - if (filp->f_mode & FMODE_RANDOM) { + /* + * Be dumb for files marked as randomly accessed, but do readahead + * inside the original request (req_size > 1). + */ + if ((filp->f_mode & FMODE_RANDOM) && req_size == 1) { force_page_cache_readahead(mapping, filp, offset, req_size); return; } -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |