Hi Martin,Sure, the performance regression appeared when comparing Novell SLES10 vs. SLES11.
On Fri, Oct 09, 2009 at 09:49:50PM +0800, Martin Schwidefsky wrote:
On Fri, 9 Oct 2009 14:29:52 +0200[snip]
Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:
On Fri, Oct 09 2009, Peter Zijlstra wrote:
On Fri, 2009-10-09 at 13:19 +0200, Ehrhardt Christian wrote:
From: Christian Ehrhardt <ehrhardt@xxxxxxxxxxxxxxxxxx>
On one hand the define VM_MAX_READAHEAD in include/linux/mm.h is just a default
and can be configured per block device queue.
On the other hand a lot of admins do not use it, therefore it is reasonable to
set a wise default.
This path allows to configure the value via Kconfig mechanisms and therefore
allow the assignment of different defaults dependent on other Kconfig symbols.
Using this, the patch increases the default max readahead for s390 improving
sequential throughput in a lot of scenarios with almost no drawbacks (only
theoretical workloads with a lot concurrent sequential read patterns on a very
low memory system suffer due to page cache trashing as expected).
The patch from Christian fixes a performance regression in the latest
distributions for s390. So we would opt for a larger value, 512KB seems
to be a good one. I have no idea what that will do to the embedded
space which is why Christian choose to make it configurable. Clearly
the better solution would be some sort of system control that can be
modified at runtime.
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..)