All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Jens Axboe <jens.axboe@oracle.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: make VM_MAX_READAHEAD configurable
Date: Mon, 12 Oct 2009 17:39:21 +0800	[thread overview]
Message-ID: <20091012093920.GA2480@localhost> (raw)
In-Reply-To: <4AD2F70C.4010506@linux.vnet.ibm.com>

On Mon, Oct 12, 2009 at 05:29:48PM +0800, Christian Ehrhardt wrote:
> Wu Fengguang wrote:
> > [SNIP]
> >>> May I ask for more details about your performance regression and why
> >>> it is related to readahead size? (we didn't change VM_MAX_READAHEAD..)
> >>>   
> >>>       
> >> Sure, the performance regression appeared when comparing Novell SLES10 
> >> vs. SLES11.
> >> While you are right Wu that the upstream default never changed so far, 
> >> SLES10 had a
> >> patch applied that set 512.
> >>     
> >
> > I see. I'm curious why SLES11 removed that patch. Did it experienced
> > some regressions with the larger readahead size?
> >
> >   
> 
> Only the obvious expected one with very low free/cacheable
> memory and a lot of parallel processes that do sequential I/O.
> The RA size scales up for all of them but 64xMaxRA then
> doesn't fit.
> 
> For example iozone with 64 threads (each on one disk for its own),
> sequential access pattern read with I guess 10 M free for cache
> suffered by ~15% due to trashing.

FYI, I just finished with a patch for dealing with readahead
thrashing.  Will do some tests and post the result :)

Thanks,
Fengguang

WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Jens Axboe <jens.axboe@oracle.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: make VM_MAX_READAHEAD configurable
Date: Mon, 12 Oct 2009 17:39:21 +0800	[thread overview]
Message-ID: <20091012093920.GA2480@localhost> (raw)
In-Reply-To: <4AD2F70C.4010506@linux.vnet.ibm.com>

On Mon, Oct 12, 2009 at 05:29:48PM +0800, Christian Ehrhardt wrote:
> Wu Fengguang wrote:
> > [SNIP]
> >>> May I ask for more details about your performance regression and why
> >>> it is related to readahead size? (we didn't change VM_MAX_READAHEAD..)
> >>>   
> >>>       
> >> Sure, the performance regression appeared when comparing Novell SLES10 
> >> vs. SLES11.
> >> While you are right Wu that the upstream default never changed so far, 
> >> SLES10 had a
> >> patch applied that set 512.
> >>     
> >
> > I see. I'm curious why SLES11 removed that patch. Did it experienced
> > some regressions with the larger readahead size?
> >
> >   
> 
> Only the obvious expected one with very low free/cacheable
> memory and a lot of parallel processes that do sequential I/O.
> The RA size scales up for all of them but 64xMaxRA then
> doesn't fit.
> 
> For example iozone with 64 threads (each on one disk for its own),
> sequential access pattern read with I guess 10 M free for cache
> suffered by ~15% due to trashing.

FYI, I just finished with a patch for dealing with readahead
thrashing.  Will do some tests and post the result :)

Thanks,
Fengguang

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

  reply	other threads:[~2009-10-12  9:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09 11:19 [PATCH] mm: make VM_MAX_READAHEAD configurable Ehrhardt Christian
2009-10-09 11:19 ` Ehrhardt Christian
2009-10-09 12:20 ` Peter Zijlstra
2009-10-09 12:20   ` Peter Zijlstra
2009-10-09 12:29   ` Jens Axboe
2009-10-09 12:29     ` Jens Axboe
2009-10-09 13:49     ` Martin Schwidefsky
2009-10-09 13:49       ` Martin Schwidefsky
2009-10-09 13:58       ` Wu Fengguang
2009-10-09 13:58         ` Wu Fengguang
2009-10-11  1:10       ` Wu Fengguang
2009-10-11  1:10         ` Wu Fengguang
2009-10-12  5:53         ` Christian Ehrhardt
2009-10-12  5:53           ` Christian Ehrhardt
2009-10-12  6:23           ` Wu Fengguang
2009-10-12  6:23             ` Wu Fengguang
2009-10-12  9:29             ` Christian Ehrhardt
2009-10-12  9:29               ` Christian Ehrhardt
2009-10-12  9:39               ` Wu Fengguang [this message]
2009-10-12  9:39                 ` Wu Fengguang
2009-10-09 21:31     ` Andrew Morton
2009-10-09 21:31       ` Andrew Morton
2009-10-10 10:53       ` Jens Axboe
2009-10-10 10:53         ` Jens Axboe
2009-10-10 12:40         ` Wu Fengguang
2009-10-10 12:40           ` Wu Fengguang
2009-10-10 17:41           ` Andrew Morton
2009-10-10 17:41             ` Andrew Morton
2009-10-09 13:14   ` Wu Fengguang
2009-10-09 13:14     ` Wu Fengguang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091012093920.GA2480@localhost \
    --to=fengguang.wu@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=ehrhardt@linux.vnet.ibm.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.