From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: [RFC][PATCH 2/2] readahead: avoid page-by-page reads on POSIX_FADV_RANDOM Date: Wed, 30 Dec 2009 13:24:02 +0800 Message-ID: <20091230052402.GB26364@localhost> References: <20091225000717.GA26949@yahoo-inc.com> <87aax18xms.fsf@basil.nowhere.org> <20091230051540.GA16308@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , Quentin Barnes , "linux-kernel@vger.kernel.org" , linux-fsdevel@vger.kernel.org, Nick Piggin , Steven Whitehouse To: Andrew Morton Return-path: Received: from mga14.intel.com ([143.182.124.37]:39427 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751571AbZL3FYF (ORCPT ); Wed, 30 Dec 2009 00:24:05 -0500 Content-Disposition: inline In-Reply-To: <20091230051540.GA16308@localhost> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: POSIX_FADV_RANDOM sets 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 readahead flag RA_FLAG_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). An implementation caveat: the set of RA_FLAG_RANDOM can be lost if the same file descriptor is being concurrent read in another thread. However it's rare event and the possible performance hit is expected to be low. In Quentin's report (http://lkml.org/lkml/2009/12/24/145), the overall (NFS read) performance of the application increased by 313%! CC: Nick Piggin CC: Andi Kleen CC: Steven Whitehouse Reported-by: Quentin Barnes Signed-off-by: Wu Fengguang --- include/linux/fs.h | 2 ++ mm/fadvise.c | 4 +++- mm/readahead.c | 6 ++++++ 3 files changed, 11 insertions(+), 1 deletion(-) --- linux.orig/include/linux/fs.h 2009-12-30 13:15:53.000000000 +0800 +++ linux/include/linux/fs.h 2009-12-30 13:17:59.000000000 +0800 @@ -896,6 +896,8 @@ struct file_ra_state { /* low 16 bits: cache miss stat for mmap accesses */ #define RA_FLAG_MMAP_MISS 0x0000ffff +#define RA_FLAG_RANDOM 0x00010000 /* POSIX_FADV_RANDOM */ + /* * Don't do flags++ directly to avoid possible overflow: * the ra fields can be accessed concurrently in a racy way. --- linux.orig/mm/fadvise.c 2009-12-30 13:02:03.000000000 +0800 +++ linux/mm/fadvise.c 2009-12-30 13:23:05.000000000 +0800 @@ -77,12 +77,14 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, lof switch (advice) { case POSIX_FADV_NORMAL: file->f_ra.ra_pages = bdi->ra_pages; + file->f_ra.flags &= ~RA_FLAG_RANDOM; break; case POSIX_FADV_RANDOM: - file->f_ra.ra_pages = 0; + file->f_ra.flags |= RA_FLAG_RANDOM; break; case POSIX_FADV_SEQUENTIAL: file->f_ra.ra_pages = bdi->ra_pages * 2; + file->f_ra.flags &= ~RA_FLAG_RANDOM; break; case POSIX_FADV_WILLNEED: if (!mapping->a_ops->readpage) { --- linux.orig/mm/readahead.c 2009-12-30 13:02:03.000000000 +0800 +++ linux/mm/readahead.c 2009-12-30 13:17:59.000000000 +0800 @@ -501,6 +501,12 @@ void page_cache_sync_readahead(struct ad if (!ra->ra_pages) return; + /* be dumb */ + if (ra->flags & RA_FLAG_RANDOM) { + force_page_cache_readahead(mapping, filp, offset, req_size); + return; + } + /* do read-ahead */ ondemand_readahead(mapping, ra, filp, false, offset, req_size); }