From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) Date: Fri, 22 Aug 2008 03:08:54 +1000 Message-ID: <20080821170854.GJ5706@disturbed> References: <20080821051508.GB5706@disturbed> <200808211700.39584.nickpiggin@yahoo.com.au> <20080821085332.GG5706@disturbed> <200808211933.34565.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: gus3 , Szabolcs Szakacsits , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com To: Nick Piggin Return-path: Received: from ipmail01.adl6.internode.on.net ([203.16.214.146]:61460 "EHLO ipmail01.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753006AbYHURI7 (ORCPT ); Thu, 21 Aug 2008 13:08:59 -0400 Content-Disposition: inline In-Reply-To: <200808211933.34565.nickpiggin@yahoo.com.au> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Aug 21, 2008 at 07:33:34PM +1000, Nick Piggin wrote: > > > But existing plugging is below the level of the elevators, and sh= ould > > > only kick in for at most tens of ms at queue idle events, so it s= ounds > > > like it may not be your problem. Elevators will need some hint to= give > > > priority to specific requests -- either via the current threads's= io > > > priority, or information attached to bios. > > > > It's getting too bloody complex, IMO. What is right for one elevato= r > > is wrong for another, so as a filesystem developer I have to pick > > one to target. >=20 > I don't really see it as too complex. If you know how you want the > request to be handled, then it should be possible to implement. That is the problem in a nutshell. Nobody can keep up with all the shiny new stuff that is being implemented,let alone the subtle behavioural differences that accumulate through such change... > > With the way the elevators have been regressing,=20 > > improving and changing behaviour, >=20 > AFAIK deadline, AS, and noop haven't significantly changed for years. Yet they've regularly shown performance regressions because other stuff has been changing around them, right? > > I am starting to think that I=20 > > should be picking the noop scheduler. > > Any 'advanced' scheduler that=20 > > is slower than the same test on the noop scheduler needs fixing... >=20 > I disagree. On devices with no seek penalty or their own queueing, > noop is often the best choice. Same for specialized apps that do > their own disk scheduling. A filesystem is nothing but a complex disk scheduler that has to handle vastly larger queues than an elevator. =D0=86f the filesystem doesn't get it's disk scheduling right, then the elevator is irrelevant because nothing will fix the I/O problems in the filesystem algorithms..... Cheers, Dave. --=20 Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html