linux-kernel - Re: [PATCH 7/9] readahead: sequential mmap readahead

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Apr 2009 16:34:13 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	linux-kernel@...r.kernel.org, npiggin@...e.de,
	torvalds@...ux-foundation.org, fengguang.wu@...el.com,
	yinghan@...gle.com
Subject: Re: [PATCH 7/9] readahead: sequential mmap readahead

On Fri, 10 Apr 2009 14:10:04 +0800
Wu Fengguang <fengguang.wu@...el.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@...e.de>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Signed-off-by: Wu Fengguang <fengguang.wu@...el.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/