From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935421Ab0BZHXw (ORCPT ); Fri, 26 Feb 2010 02:23:52 -0500 Received: from mtagate2.uk.ibm.com ([194.196.100.162]:38289 "EHLO mtagate2.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935398Ab0BZHXu (ORCPT ); Fri, 26 Feb 2010 02:23:50 -0500 Message-ID: <4B8776FC.30409@linux.vnet.ibm.com> Date: Fri, 26 Feb 2010 08:23:40 +0100 From: Christian Ehrhardt User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Wu Fengguang CC: Andrew Morton , Jens Axboe , Matt Mackall , Chris Mason , Peter Zijlstra , Clemens Ladisch , Olivier Galibert , Vivek Goyal , Nick Piggin , Linux Memory Management List , "linux-fsdevel@vger.kernel.org" , LKML , Rik van Riel Subject: Re: [PATCH 05/15] readahead: limit readahead size for small memory systems References: <20100224031001.026464755@intel.com> <20100224031054.307027163@intel.com> <4B869682.9010709@linux.vnet.ibm.com> <20100226022907.GA22226@localhost> In-Reply-To: <20100226022907.GA22226@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 >> > Signed-off-by: Wu Fengguang >> >> 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 > CC: Christian Ehrhardt > Signed-off-by: Wu Fengguang > --- > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [PATCH 05/15] readahead: limit readahead size for small memory systems Date: Fri, 26 Feb 2010 08:23:40 +0100 Message-ID: <4B8776FC.30409@linux.vnet.ibm.com> References: <20100224031001.026464755@intel.com> <20100224031054.307027163@intel.com> <4B869682.9010709@linux.vnet.ibm.com> <20100226022907.GA22226@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Andrew Morton , Jens Axboe , Matt Mackall , Chris Mason , Peter Zijlstra , Clemens Ladisch , Olivier Galibert , Vivek Goyal , Nick Piggin , Linux Memory Management List , "linux-fsdevel@vger.kernel.org" , LKML , Rik van Riel To: Wu Fengguang Return-path: In-Reply-To: <20100226022907.GA22226@localhost> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org Unfortunately without a chance to measure this atm, this patch now looks=20 really good to me. Thanks for adapting it to a read-ahead only per mem limit. Acked-by: Christian Ehrhardt 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 con= sumed >> > 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 o= n >> > 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 =3D> 512KB readahead size >> > 128MB mem =3D> 128KB readahead size >> > 32MB mem =3D> 32KB readahead size (minimal) >> > >> > Strictly speaking, only read-around size has to be limited. Howeve= r we >> > don't bother to seperate read-around size from read-ahead size for = now. >> > >> > CC: Matt Mackall >> > Signed-off-by: Wu Fengguang >> >> What I state here is for read ahead in a "multi iozone sequential"=20 >> setup, I can't speak for real "read around" workloads. >> So probably your table is fine to cover read-around+read-ahead in one=20 >> number. >=20 > OK. >=20 >> 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=20 >> didn't see major trashing or memory pressure impact. >=20 > In fact I'd expect a 64MB box to also benefit from 512kb readahead :) >=20 >> Therefore I would recommend a table like: >> >=3D256MB mem =3D> 512KB readahead size >> 128MB mem =3D> 128KB readahead size >> 32MB mem =3D> 32KB readahead size (minimal) >=20 > So, I'm fed up with compromising the read-ahead size with read-around > size. >=20 > 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. >=20 > Thanks, > Fengguang > --- > readahead: limit read-ahead size for small memory systems >=20 > When lifting the default readahead size from 128KB to 512KB, > make sure it won't add memory pressure to small memory systems. >=20 > For read-ahead, the memory pressure is mainly readahead buffers consume= d > 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. >=20 > 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". >=20 > This patch presents a straightforward solution: to limit default > read-ahead size proportional to available system memory, ie. > 512MB mem =3D> 512KB readahead size > 128MB mem =3D> 128KB readahead size > 32MB mem =3D> 32KB readahead size >=20 > CC: Matt Mackall > CC: Christian Ehrhardt > Signed-off-by: Wu Fengguang > --- > mm/filemap.c | 2 +- > mm/readahead.c | 22 ++++++++++++++++++++++ > 2 files changed, 23 insertions(+), 1 deletion(-) >=20 > --- 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 =3D max_sane_readahead(ra->ra_pages); > + ra_pages =3D min(ra->ra_pages, roundup_pow_of_two(totalram_pages / 10= 24)); > if (ra_pages) { > ra->start =3D max_t(long, 0, offset - ra_pages/2); > ra->size =3D ra_pages; --=20 Gr=FCsse / 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id BE9D06B0078 for ; Fri, 26 Feb 2010 02:23:50 -0500 (EST) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate5.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o1Q7NmBC013585 for ; Fri, 26 Feb 2010 07:23:48 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1Q7Nm7W1327252 for ; Fri, 26 Feb 2010 07:23:48 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o1Q7NlOj018439 for ; Fri, 26 Feb 2010 07:23:48 GMT Message-ID: <4B8776FC.30409@linux.vnet.ibm.com> Date: Fri, 26 Feb 2010 08:23:40 +0100 From: Christian Ehrhardt MIME-Version: 1.0 Subject: Re: [PATCH 05/15] readahead: limit readahead size for small memory systems References: <20100224031001.026464755@intel.com> <20100224031054.307027163@intel.com> <4B869682.9010709@linux.vnet.ibm.com> <20100226022907.GA22226@localhost> In-Reply-To: <20100226022907.GA22226@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org To: Wu Fengguang Cc: Andrew Morton , Jens Axboe , Matt Mackall , Chris Mason , Peter Zijlstra , Clemens Ladisch , Olivier Galibert , Vivek Goyal , Nick Piggin , Linux Memory Management List , "linux-fsdevel@vger.kernel.org" , LKML , Rik van Riel List-ID: 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 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 >> > Signed-off-by: Wu Fengguang >> >> 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 > CC: Christian Ehrhardt > Signed-off-by: Wu Fengguang > --- > 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; -- Grusse / 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: email@kvack.org