From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754717AbZDFIM4 (ORCPT ); Mon, 6 Apr 2009 04:12:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752104AbZDFIMr (ORCPT ); Mon, 6 Apr 2009 04:12:47 -0400 Received: from brick.kernel.dk ([93.163.65.50]:38535 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752062AbZDFIMr (ORCPT ); Mon, 6 Apr 2009 04:12:47 -0400 Date: Mon, 6 Apr 2009 10:12:44 +0200 From: Jens Axboe To: Theodore Tso Cc: Linus Torvalds , Linux Kernel Developers List , Ext4 Developers List Subject: Re: [GIT PULL] Ext3 latency fixes Message-ID: <20090406081244.GR5178@kernel.dk> References: <1238742067-30814-1-git-send-email-tytso@mit.edu> <20090404135719.GA9812@mit.edu> <20090404151649.GE5178@kernel.dk> <20090404191826.GE9812@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090404191826.GE9812@mit.edu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 04 2009, Theodore Tso wrote: > On Sat, Apr 04, 2009 at 05:16:50PM +0200, Jens Axboe wrote: > > Big nack on this patch. Ted, this is EXACTLY where I told you we saw big > > write regressions (sqlite performance drops by a factor of 4-5). Do a > > git log on fs/buffer.c and see the original patch (which does what your > > patch does) and the later revert. > > You mean this revert, right? > > commit 78f707bfc723552e8309b7c38a8d0cc51012e813 > Author: Jens Axboe > Date: Tue Feb 17 13:59:08 2009 +0100 > > block: revert part of 18ce3751ccd488c78d3827e9f6bf54e6322676fb > > The above commit added WRITE_SYNC and switched various places to using > that for committing writes that will be waited upon immediately after > submission. However, this causes a performance regression with AS and CFQ > for ext3 at least, since sync_dirty_buffer() will submit some writes with > WRITE_SYNC while ext3 has sumitted others dependent writes without the sync > flag set. This causes excessive anticipation/idling in the IO scheduler > because sync and async writes get interleaved, causing a big performance > regression for the below test case (which is meant to simulate sqlite > like behaviour).... > > OK, let me test things out first, but note that with the changes that > Linus has already accepted, this may not be an issue --- since we've > now fixed ext3 to submit those dependent writes with the SYNC flag > now. So I'm not sure the performance regression still applies, but > I'll test using the test case supplied in the rest of the commit log > and get back to you. Yep that's the one. I'll throw some testing together here, too. -- Jens Axboe