From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: Wu Fengguang <fengguang.wu@intel.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 11:29:48 +0200 [thread overview]
Message-ID: <4AD2F70C.4010506@linux.vnet.ibm.com> (raw)
In-Reply-To: <20091012062317.GA10719@localhost>
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.
But that is a acceptable regression because it is no relevant
customer scenario, while the benefits apply to customer scenarios.
[...]
>> And as Andrew mentioned the diversity of devices cause any default to be
>> wrong for one
>> or another installation. To solve that the udev approach can also differ
>> between different
>> device types (might be easier on s390 than on other architectures
>> because I need to take
>> care of two disk types atm - and both shold get 512).
>>
>
> I guess it's not a general solution for all. There are so many
> devices in the world, and we have not yet considered the
> memory/workload combinations.
>
I completely agree, let me fix "my" issue per udev for now.
And if some day the readahead mechanism evolves and
doesn't need any max RA at all we can all be happy.
[...]
--
Grusse / regards, Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
--
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>
next prev parent reply other threads:[~2009-10-12 9:30 UTC|newest]
Thread overview: 15+ 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 12:20 ` Peter Zijlstra
2009-10-09 12:29 ` Jens Axboe
2009-10-09 13:49 ` Martin Schwidefsky
2009-10-09 13:58 ` Wu Fengguang
2009-10-11 1:10 ` Wu Fengguang
2009-10-12 5:53 ` Christian Ehrhardt
2009-10-12 6:23 ` Wu Fengguang
2009-10-12 9:29 ` Christian Ehrhardt [this message]
2009-10-12 9:39 ` Wu Fengguang
2009-10-09 21:31 ` Andrew Morton
2009-10-10 10:53 ` Jens Axboe
2009-10-10 12:40 ` Wu Fengguang
2009-10-10 17:41 ` Andrew Morton
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=4AD2F70C.4010506@linux.vnet.ibm.com \
--to=ehrhardt@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).