Yes, exactly. The patch for fixing this regression is trivial.
However it may be better to revert 1cf6e7d83 for 2.6.29,
and merge 1cf6e7d83 together with this patch for 2.6.30-rc1.
This allows a larger window for testing out the possible impacts
on other workloads.
Thanks,
Fengguang
---
writeback: double the dirty thresholds
Enlarge default dirty ratios from 5/10 to 10/20.
This fixes [Bug #12809] iozone regression with 2.6.29-rc6.
The iozone benchmarks are performed on a 1200M file, with 8GB ram.
iozone -i 0 -i 1 -i 2 -i 3 -i 4 -r 4k -s 64k -s 512m -s 1200m -b tmp.xls
iozone -B -r 4k -s 64k -s 512m -s 1200m -b tmp.xls
The performance regression is triggered by commit 1cf6e7d83bf3(mm: task
dirty accounting fix), which makes more correct/thorough dirty accounting.
The default 5/10 dirty ratios were picked (a) with the old dirty
logic and (b) largely at random and (c) designed to be aggressive. In
particular, that (a) means that having fixed some of the dirty accounting,
maybe the real bug is now that it was always too aggressive, just hidden
by an accounting issue.
The enlarged 10/20 dirty ratios are just about enough to fix the regression.
Cc: Nick Piggin <npiggin@suse.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: "Lin, Ming M" <ming.m.lin@intel.com>
Tested-by: "Lin, Ming M" <ming.m.lin@intel.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
mm/page-writeback.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- mm.orig/mm/page-writeback.c
+++ mm/mm/page-writeback.c
@@ -66,7 +66,7 @@ static inline long sync_writeback_pages(
/*
* Start background writeback (via pdflush) at this percentage
*/
-int dirty_background_ratio = 5;
+int dirty_background_ratio = 10;
/*
* dirty_background_bytes starts at 0 (disabled) so that it is a function of
@@ -83,7 +83,7 @@ int vm_highmem_is_dirtyable;
/*
* The generator of dirty data starts writeback at this ...
