From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755557AbZDEPEV (ORCPT ); Sun, 5 Apr 2009 11:04:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754428AbZDEPEG (ORCPT ); Sun, 5 Apr 2009 11:04:06 -0400 Received: from casper.infradead.org ([85.118.1.10]:40459 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754052AbZDEPEF (ORCPT ); Sun, 5 Apr 2009 11:04:05 -0400 Date: Sun, 5 Apr 2009 08:05:30 -0700 From: Arjan van de Ven To: Theodore Tso Cc: Jens Axboe , Linus Torvalds , Linux Kernel Developers List , Ext4 Developers List Subject: Re: [GIT PULL] Ext3 latency fixes Message-ID: <20090405080530.0859b9a6@infradead.org> In-Reply-To: <20090405001005.GA7553@mit.edu> References: <20090404135719.GA9812@mit.edu> <20090404151649.GE5178@kernel.dk> <20090404173412.GF5178@kernel.dk> <20090404180108.GH5178@kernel.dk> <20090404232222.GA7480@mit.edu> <20090404163349.20df1208@infradead.org> <20090405001005.GA7553@mit.edu> Organization: Intel X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 4 Apr 2009 20:10:05 -0400 Theodore Tso wrote: > On Sat, Apr 04, 2009 at 04:33:49PM -0700, Arjan van de Ven wrote: > > > However, the full latency fixes all the writes are synchronous, > > > so it must be the case that the delays are caused by the fact > > > that queue is getting implicitly unplugged after the synchronous > > > write, and the problem is no longer the mixing of WRITE and > > > WRITE_SYNC requests as posted in the commit log for 78f707bf. If > > > we remove the automatic unplug for WRITE_SYNC requests, and add > > > an explicit unplug where it is needed, that should fix the > > > performance regression for this particular sqlite test case. > > > > removing the unplug is bound to be bad; after all we're waiting on > > the IO. But maybe it should be "make the unplug a REALLY short > > time". At least for rotating storage. For non-rotating .. I'd never > > wait. > > Ext3 needs to submit a large number of blocks for writing with > WRITE_SYNC priority, without unplugging the queue, until they are all > submitted. Then we want to let things rip. (Hence the "add an > explicit unplug where it is needed".) > > It may be that it's easier from an less-lines-of-the-kernels-to-change > point of view to add a WRITE_SYNC_PLUGGED which doesn't do the unplug, > and keep WRITE_SNYC as having the implicit unplug. Or maybe it would > be better to completely separate the "send a write which is marked as > SYNC" from the "implicit unplug" in the API. I think there's actually 3 cases: * Normal write with normal plugging rules * Write that should be "sync" priority, but which should explicitly NOT unplug, even if it otherwise would have happened, because the caller will, as part of the contract of the API, do the unplug when all IO is submitted. (a bit like tcp/cork) * Write that is sync priority and is the last one of a sequence, and thus should unplug immediately. I can even imagine using a temporary/special queue for the 2nd case, and then splice that into the regular queue when the final IO comes in, in one go. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org