Date: Fri, 10 Apr 2009 16:34:13 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: linux-kernel@vger.kernel.org, npiggin@suse.de,
       torvalds@linux-foundation.org, fengguang.wu@intel.com,
       yinghan@google.com
Subject: Re: [PATCH 7/9] readahead: sequential mmap readahead
Message-Id: <20090410163413.a014bde0.akpm@linux-foundation.org>
In-Reply-To: <20090410061254.719205499@intel.com>
References: <20090410060957.442203404@intel.com>
	<20090410061254.719205499@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2774
Lines: 70

On Fri, 10 Apr 2009 14:10:04 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:

> Auto-detect sequential mmap reads and do readahead for them.
> 
> The sequential mmap readahead will be triggered when
> - sync readahead: it's a major fault and (prev_offset == offset-1);
> - async readahead: minor fault on PG_readahead page with valid readahead state.
> 
> The benefits of doing readahead instead of read-around:
> - less I/O wait thanks to async readahead
> - double real I/O size and no more cache hits
> 
> The single stream case is improved a little.
> For 100,000 sequential mmap reads:
> 
>                                     user       system    cpu        total
> (1-1)  plain -mm, 128KB readaround: 3.224      2.554     48.40%     11.838
> (1-2)  plain -mm, 256KB readaround: 3.170      2.392     46.20%     11.976
> (2)  patched -mm, 128KB readahead:  3.117      2.448     47.33%     11.607
> 
> The patched (2) has smallest total time, since it has no cache hit overheads
> and less I/O block time(thanks to async readahead). Here the I/O size
> makes no much difference, since there's only one single stream.
> 
> Note that (1-1)'s real I/O size is 64KB and (1-2)'s real I/O size is 128KB,
> since the half of the read-around pages will be readahead cache hits.
> 
> This is going to make _real_ differences for _concurrent_ IO streams.
> 
> Cc: Nick Piggin <npiggin@suse.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> ---
>  mm/filemap.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- mm.orig/mm/filemap.c
> +++ mm/mm/filemap.c
> @@ -1471,7 +1471,8 @@ static void do_sync_mmap_readahead(struc
>  	if (VM_RandomReadHint(vma))
>  		return;
>  
> -	if (VM_SequentialReadHint(vma)) {
> +	if (VM_SequentialReadHint(vma) ||
> +			offset - 1 == (ra->prev_pos >> PAGE_CACHE_SHIFT)) {
>  		page_cache_sync_readahead(mapping, ra, file, offset, 1);
>  		return;
>  	}
> 

We've always believed that readaround was beneficial for more random
access patterns - classically faulting in an executable.  Although I
don't recall that this belief was very well substantiated.

(The best results I ever got was by doing readaround and setting the
size to a few MB, so we slurp the entire executable into memory in one
hit.  lol.)

So my question is: what is the probability that this change will
inadvertently cause a randomish-access workload to fall into readahead
(rather than readaround) mode, and what is the impact when this
happens?


--
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/