Re: [GIT PULL] Ext3 latency fixes

From: "Indan Zupancic" <indan@nul.nu>
To: "Linus Torvalds" <torvalds@linux-foundation.org>
Cc: "Jens Axboe" <jens.axboe@oracle.com>,
	"Theodore Tso" <tytso@mit.edu>,
	"Linux Kernel Developers List" <linux-kernel@vger.kernel.org>,
	"Ext4 Developers List" <linux-ext4@vger.kernel.org>
Subject: Re: [GIT PULL] Ext3 latency fixes
Date: Tue, 7 Apr 2009 17:39:30 +0200 (CEST)	[thread overview]
Message-ID: <b7bb17e28bad417d37765814626bb886.squirrel@webmail.greenhost.nl> (raw)
In-Reply-To: <alpine.LFD.2.00.0904040854470.3915@localhost.localdomain>

On Sat, April 4, 2009 17:57, Linus Torvalds wrote:
>
> On Sat, 4 Apr 2009, 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. No idea why you are now suggestion
>> making that exact change?!
>
> Jens, if I can re-create the 'fsync' times (I haven't yet), then the
> default scheduler _will_ be switched to AS.

http://bugzilla.kernel.org/show_bug.cgi?id=5900

I can try it with a different fs, kernel or machine as well.

To me it seems this stuff is way more tricky than it should be, with
all the interaction between fs, vm, io schedulers and hardware.
Perhaps there's a need for one sophisticated io scheduler that gets
enough information from the rest to make the right decisions. Sync
or not sync isn't enough info.