Received: with ECARTIS (v1.0.0; list xfs); Mon, 25 Aug 2008 20:06:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m7Q36kuF018915 for ; Mon, 25 Aug 2008 20:06:46 -0700 X-ASG-Debug-ID: 1219720087-10af020a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BA0171A4828C for ; Mon, 25 Aug 2008 20:08:08 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id M63KD7tc87jf1t8e for ; Mon, 25 Aug 2008 20:08:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtACAI8Os0h5LD0wiGdsb2JhbACSLAEBAQ8gpC6Baw X-IronPort-AV: E=Sophos;i="4.32,268,1217773800"; d="scan'208";a="180348679" Received: from ppp121-44-61-48.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.61.48]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Aug 2008 12:38:01 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KXouV-0008PL-MH; Tue, 26 Aug 2008 13:07:59 +1000 Date: Tue, 26 Aug 2008 13:07:59 +1000 From: Dave Chinner To: Jamie Lokier Cc: Nick Piggin , gus3 , Szabolcs Szakacsits , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) Subject: Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) Message-ID: <20080826030759.GY5706@disturbed> Mail-Followup-To: Jamie Lokier , Nick Piggin , gus3 , Szabolcs Szakacsits , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20080821051508.GB5706@disturbed> <200808211933.34565.nickpiggin@yahoo.com.au> <20080821170854.GJ5706@disturbed> <200808221229.11069.nickpiggin@yahoo.com.au> <20080825015922.GP5706@disturbed> <20080825120146.GC20960@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080825120146.GC20960@shareable.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1219720089 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.3732 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/8089/Mon Aug 25 17:28:51 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 17724 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Aug 25, 2008 at 01:01:47PM +0100, Jamie Lokier wrote: > Dave Chinner wrote: > > To keep on top of this, we keep adding new variations and types and > > expect the filesystems to make best use of them (without > > documentation) to optimise for certain situations. Example - the > > new(ish) BIO_META tag that only CFQ understands. I can change the > > way XFS issues bios to use this tag to make CFQ behave the same way > > it used to w.r.t. metadata I/O from XFS, but then the deadline and > > AS will probably regress because they don't understand that tag and > > still need the old optimisations that just got removed. Ditto for > > prioritised bio dispatch - CFQ supports it but none of the others > > do. > > There's nothing wrong with adding BIO_META (for example) and other > hints in _principle_. You should be able to ignore it with no adverse > effects. If its not used by a filesystem (and there's nothing else > competing to use the same disk), I would hope to see the same > performance as other kernels which don't have it. Right, but it's what we need to do to make use of that optimisation that is the problem. For XFS, it needs to replace the current BIO_SYNC hints we use (even for async I/O) to get metadata dispatched quickly. i.e. CFQ looks at the sync flag first then the meta flag. Hence to take advantage of it, we need to remove the BIO_SYNC hints we currently use which will change the behaviour on all other elevators as a side effect. This is the optimisation problem I'm refering to - the BIO_SYNC usage was done years ago to get metadata dispatched quickly because that is what all the elevators did with sync I/O. Now to optimise for CFQ we need to remove that BIO_SYNC optimisation which is still valid for the other elevators.... > If the elevators are being changed in such a way that old filesystem > code which doesn't use new hint bits is running significantly slower, > surely that's blatant elevator regression, and that's where the bugs > should be reported and fixed? Sure, but in reality getting ppl to go through the pain of triage is extremely rare because it only takes 10s to change elevators and make the problem go away... Cheers, Dave. -- Dave Chinner david@fromorbit.com