From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: Re: Ext3 sequential read performance drop 2.6.29 -> 2.6.30,2.6.31,... Date: Tue, 3 Nov 2009 08:50:30 -0800 Message-ID: <20091103085030.6c2f3304.akpm@linux-foundation.org> References: <20091013120955.6bd5844b@smartjog.com> <20091102135554.b10ece3e.akpm@linux-foundation.org> <20091103100645.GA13118@infradead.org> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, linux-raid@vger.kernel.org, device-mapper development , Laurent CORBES , linux-kernel@vger.kernel.org To: "NeilBrown" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com List-Id: linux-fsdevel.vger.kernel.org On Tue, 3 Nov 2009 21:42:30 +1100 "NeilBrown" wrote: > On Tue, November 3, 2009 9:06 pm, Christoph Hellwig wrote: > > On Mon, Nov 02, 2009 at 01:55:54PM -0800, Andrew Morton wrote: > >> On Tue, 13 Oct 2009 12:09:55 +0200 > >> Laurent CORBES wrote: > >> > >> > Hi all, > >> > > >> > While benchmarking some systems I discover a big sequential read > >> performance > >> > drop using ext3 on ~ big files. The drop seems to be introduced in > >> 2.6.30. I'm > >> > testing with 2.6.28.6 -> 2.6.29.6 -> 2.6.30.4 -> 2.6.31.3. > >> > >> Seems that large performance regressions aren't of interest to this > >> list :( > > > > No sure which list you mean, but dm-devel is for dm, not md. bah. > We're also > > seeing similarly massive performance drops with md and ext3/xfs as > > already reported on the list. Someone tracked it down to writeback > > changes as usual, but there it got stuck. > > I'm still looking - running some basic tests on 4 filesystems over > half a dozen recent kernels to see what has been happening. > > I have a suspicion that there a multiple problems. > In particular, XFS has a strange degradation which was papered over > by commit c8a4051c3731b. > I'm beginning to wonder if it was caused by commit 17bc6c30cf6bf > but I haven't actually tested that yet. I think Laurent's workload involves only reads, with no writes.