Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Aug 2008 01:52:55 -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 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m7L8qptR025753 for ; Thu, 21 Aug 2008 01:52:51 -0700 X-ASG-Debug-ID: 1219308850-14aa02ba0000-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 48BE43BA0CB for ; Thu, 21 Aug 2008 01:54:11 -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 t6XEShzHaP7OquvJ for ; Thu, 21 Aug 2008 01:54:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALDHrEh5LD0w/2dsb2JhbAC1WoFm X-IronPort-AV: E=Sophos;i="4.32,244,1217773800"; d="scan'208";a="176333807" 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; 21 Aug 2008 18:23:56 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KW5vC-0003gF-4h; Thu, 21 Aug 2008 18:53:34 +1000 Date: Thu, 21 Aug 2008 18:53:32 +1000 From: Dave Chinner To: Nick Piggin Cc: 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: <20080821085332.GG5706@disturbed> Mail-Followup-To: 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> <684252.68814.qm@web34508.mail.mud.yahoo.com> <20080821061443.GD5706@disturbed> <200808211700.39584.nickpiggin@yahoo.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808211700.39584.nickpiggin@yahoo.com.au> 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: 1219308852 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.3280 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/8061/Wed Aug 20 17:00:17 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 17654 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 Thu, Aug 21, 2008 at 05:00:39PM +1000, Nick Piggin wrote: > On Thursday 21 August 2008 16:14, Dave Chinner wrote: > > > I think that we need to issue explicit unplugs to get the log I/O > > dispatched the way we want on all elevators and stop trying to > > give elevators implicit hints by abusing the bio types and hoping > > they do the right thing.... > > FWIW, my explicit plugging idea is still hanging around in one of > Jens' block trees (actually he refreshed it a couple of months ago). > > It provides an API for VM or filesystems to plug and unplug > requests coming out of the current process, and it can reduce the > need to idle the queue. Needs more performance analysis and tuning > though. We've already got plenty of explicit unplugs in XFS to get stuff moving quickly - I'll just have to add another.... > But existing plugging is below the level of the elevators, and should > only kick in for at most tens of ms at queue idle events, so it sounds > 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 elevator is wrong for another, so as a filesystem developer I have to pick one to target. With the way the elevators have been regressing, improving and changing behaviour, I am starting to think that I should be picking the noop scheduler. Any 'advanced' scheduler that is slower than the same test on the noop scheduler needs fixing... Cheers, Dave. -- Dave Chinner david@fromorbit.com