Re: [PATCH 05/15] readahead: limit readahead size for small memory systems

[Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>]

Unfortunately without a chance to measure this atm, this patch now looks 
really good to me.
Thanks for adapting it to a read-ahead only per mem limit.
Acked-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>


Wu Fengguang wrote:
> On Thu, Feb 25, 2010 at 11:25:54PM +0800, Christian Ehrhardt wrote:
>>
>> Wu Fengguang wrote:
>>  > When lifting the default readahead size from 128KB to 512KB,
>>  > make sure it won't add memory pressure to small memory systems.
>>  >
>>  > For read-ahead, the memory pressure is mainly readahead buffers consumed
>>  > by too many concurrent streams. The context readahead can adapt
>>  > readahead size to thrashing threshold well.  So in principle we don't
>>  > need to adapt the default _max_ read-ahead size to memory pressure.
>>  >
>>  > For read-around, the memory pressure is mainly read-around misses on
>>  > executables/libraries. Which could be reduced by scaling down
>>  > read-around size on fast "reclaim passes".
>>  >
>>  > This patch presents a straightforward solution: to limit default
>>  > readahead size proportional to available system memory, ie.
>>  >                 512MB mem => 512KB readahead size
>>  >                 128MB mem => 128KB readahead size
>>  >                  32MB mem =>  32KB readahead size (minimal)
>>  >
>>  > Strictly speaking, only read-around size has to be limited.  However we
>>  > don't bother to seperate read-around size from read-ahead size for now.
>>  >
>>  > CC: Matt Mackall <mpm@selenic.com>
>>  > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
>>
>> What I state here is for read ahead in a "multi iozone sequential" 
>> setup, I can't speak for real "read around" workloads.
>> So probably your table is fine to cover read-around+read-ahead in one 
>> number.
> 
> OK.
> 
>> I have tested 256MB mem systems with 512kb readahead quite a lot.
>> On those 512kb is still by far superior to smaller readaheads and I 
>> didn't see major trashing or memory pressure impact.
> 
> In fact I'd expect a 64MB box to also benefit from 512kb readahead :)
> 
>> Therefore I would recommend a table like:
>>                 >=256MB mem => 512KB readahead size
>>                   128MB mem => 128KB readahead size
>>                    32MB mem =>  32KB readahead size (minimal)
> 
> So, I'm fed up with compromising the read-ahead size with read-around
> size.
> 
> There is no good to introduce a read-around size to confuse the user
> though.  Instead, I'll introduce a read-around size limit _on top of_
> the readahead size. This will allow power users to adjust
> read-ahead/read-around size at the same time, while saving the low end
> from unnecessary memory pressure :) I made the assumption that low end
> users have no need to request a large read-around size.
> 
> Thanks,
> Fengguang
> ---
> readahead: limit read-ahead size for small memory systems
> 
> When lifting the default readahead size from 128KB to 512KB,
> make sure it won't add memory pressure to small memory systems.
> 
> For read-ahead, the memory pressure is mainly readahead buffers consumed
> by too many concurrent streams. The context readahead can adapt
> readahead size to thrashing threshold well.  So in principle we don't
> need to adapt the default _max_ read-ahead size to memory pressure.
> 
> For read-around, the memory pressure is mainly read-around misses on
> executables/libraries. Which could be reduced by scaling down
> read-around size on fast "reclaim passes".
> 
> This patch presents a straightforward solution: to limit default
> read-ahead size proportional to available system memory, ie.
>                 512MB mem => 512KB readahead size
>                 128MB mem => 128KB readahead size
>                  32MB mem =>  32KB readahead size
> 
> CC: Matt Mackall <mpm@selenic.com>
> CC: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> ---
>  mm/filemap.c   |    2 +-
>  mm/readahead.c |   22 ++++++++++++++++++++++
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> --- linux.orig/mm/filemap.c	2010-02-26 10:04:28.000000000 +0800
> +++ linux/mm/filemap.c	2010-02-26 10:08:33.000000000 +0800
> @@ -1431,7 +1431,7 @@ static void do_sync_mmap_readahead(struc
>  	/*
>  	 * mmap read-around
>  	 */
> -	ra_pages = max_sane_readahead(ra->ra_pages);
> +	ra_pages = min(ra->ra_pages, roundup_pow_of_two(totalram_pages / 1024));
>  	if (ra_pages) {
>  		ra->start = max_t(long, 0, offset - ra_pages/2);
>  		ra->size = ra_pages;

-- 

Grüsse / regards, Christian Ehrhardt
IBM Linux Technology Center, System z Linux Performance

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>