Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264412AbTE0Wof (ORCPT ); Tue, 27 May 2003 18:44:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264405AbTE0Wof (ORCPT ); Tue, 27 May 2003 18:44:35 -0400 Received: from ppp-217-133-42-200.cust-adsl.tiscali.it ([217.133.42.200]:12162 "EHLO dualathlon.random") by vger.kernel.org with ESMTP id S264403AbTE0Wob (ORCPT ); Tue, 27 May 2003 18:44:31 -0400 Date: Wed, 28 May 2003 00:58:13 +0200 From: Andrea Arcangeli To: Andrew Morton Cc: marcelo@conectiva.com.br, m.c.p@wolk-project.de, linux-kernel@vger.kernel.org, c-d.hailfinger.kernel.2003@gmx.net, manish@storadinc.com, christian.klose@freenet.de, wli@holomorphy.com Subject: Re: 2.4.20: Proccess stuck in __lock_page ... Message-ID: <20030527225812.GE1453@dualathlon.random> References: <200305272004.02376.m.c.p@wolk-project.de> <20030527182547.GG3767@dualathlon.random> <20030527200339.GI3767@dualathlon.random> <20030527202520.GN3767@dualathlon.random> <20030527151830.40b3d281.akpm@digeo.com> <20030527223800.GC1453@dualathlon.random> <20030527154049.22411c59.akpm@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030527154049.22411c59.akpm@digeo.com> User-Agent: Mutt/1.4i X-GPG-Key: 1024D/68B9CB43 X-PGP-Key: 1024R/CB4660B9 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2375 Lines: 53 On Tue, May 27, 2003 at 03:40:49PM -0700, Andrew Morton wrote: > Andrea Arcangeli wrote: > > > > On Tue, May 27, 2003 at 03:18:30PM -0700, Andrew Morton wrote: > > > Andrea Arcangeli wrote: > > > > > > > > However the last numbers from Randy showed my tree going faster than 2.5 > > > > with bonnie and tiotest so I think we don't need to worry and I would > > > > probably not fix it in a different way in 2.4 even if it would mean a 1% > > > > degradation. > > > > > > That could be because -aa quadruples the size of the VM readahead window. > > > > > > Changes such as that should be removed when assessing the performance > > > impact of this particular patch. > > > > I understand that was a generic benchmark against 2.5, not meant to > > evaluate the effect of the fixed readahead (see the name of the patch > > "readahead-got-broken-somehwere"). I don't see any good reason why > > should Randy cripple down my tree before benchmarking against 2.5? if > > something it's ok to apply some of my patches to 2.5, that's great, the > > other way around not IMHO. > > > > No. > > What I am saying is that evaluation of the effect of an IO scheduler change > cannot be performed when there is a 4:1 change in the readhead window present > in the same tree. > > ie: we cannot conclude anything about the effect of the IO scheduler change > from Randy's numbers. Too many variables. an accurate evaluation can't be made from such comparison, but I never claimed that to be an accurate evaluation, I just said we don't need to worry, == "can't be too bad". I just said it can't be too bad. and this is true, you even admit that a readahead change for sure has more impact than whatever change the fix-pausing generated. That's all I meant. Can't be too bad. the fact mainline doesn't do readahead properly is much worse thing than whatever slowdown can be generated by the fix pausing. Furthmore I said we can deduce the accurate numbers from bigbox.html, with very minor changes (not 2.4 vs 2.5) that as well shows the fix for the deadlock not measurable as far as I can tell. Andrea - 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/