Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756939AbZCWA6c (ORCPT ); Sun, 22 Mar 2009 20:58:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756844AbZCWA6P (ORCPT ); Sun, 22 Mar 2009 20:58:15 -0400 Received: from mga03.intel.com ([143.182.124.21]:32780 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754316AbZCWA6N (ORCPT ); Sun, 22 Mar 2009 20:58:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,404,1233561600"; d="scan'208";a="122993815" Date: Mon, 23 Mar 2009 08:57:38 +0800 From: Wu Fengguang To: Ingo Molnar Cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , Adrian Bunk , Andrew Morton , Linus Torvalds , Natalie Protasevich , Kernel Testers List , Network Development , Linux ACPI , Linux PM List , Linux SCSI List , Nick Piggin , Peter Zijlstra Subject: Re: 2.6.29-rc8-git5: Reported regressions from 2.6.28 Message-ID: <20090323005738.GB6003@localhost> References: <20090321200534.GA30238@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090321200534.GA30238@elte.hu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3177 Lines: 83 On Sun, Mar 22, 2009 at 04:05:34AM +0800, Ingo Molnar wrote: > > * Rafael J. Wysocki wrote: > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12809 > > Subject : iozone regression with 2.6.29-rc6 > > Submitter : Lin Ming > > Date : 2009-02-27 9:13 (23 days old) > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018 > > References : http://marc.info/?l=linux-kernel&m=123572630504360&w=4 > > http://lkml.org/lkml/2009/3/14/265 > > Handled-By : Wu Fengguang > > I think this was tracked back to the effective halving of > dirty_ratio by 1cf6e7d83 ("mm: task dirty accounting fix") and > doubling the ratio fixed the iozone regression. 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 Cc: Peter Zijlstra Cc: Linus Torvalds Reported-by: "Lin, Ming M" Tested-by: "Lin, Ming M" Signed-off-by: Wu Fengguang --- 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 percentage */ -int vm_dirty_ratio = 10; +int vm_dirty_ratio = 20; /* * vm_dirty_bytes starts at 0 (disabled) so that it is a function of -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/