Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Aug 2008 22:58:53 -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.1 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 m7L5woHT007296 for ; Wed, 20 Aug 2008 22:58:50 -0700 X-ASG-Debug-ID: 1219298410-50e103690000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34508.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 3AA921A1D9F5 for ; Wed, 20 Aug 2008 23:00:10 -0700 (PDT) Received: from web34508.mail.mud.yahoo.com (web34508.mail.mud.yahoo.com [66.163.178.174]) by cuda.sgi.com with SMTP id HUo0zO6s2sxZrERW for ; Wed, 20 Aug 2008 23:00:10 -0700 (PDT) Received: (qmail 69539 invoked by uid 60001); 21 Aug 2008 06:00:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=5r9SCkn72plnsdxQRs0xpJlZrzvaxetZgzV6pKkSh2zjmQC53tqOVZo6dlA80pfPSqaUCkxB10gq/Sogj2JcRfQzD+NzuC1Mjd1+D7HZLqrZT7F2QBv/uKyz9h78YkvltVP7EKe9tbOmW2T2vWFGdZuct+40ZmsaeriSeV83k3c=; X-YMail-OSG: gMal2EIVM1nqHJ6pLYmPKeWvFsK25Z5VCBFHtUYgKrXWUFZCNEU_wohlJ8Qhh6fCQwLHt6vARMmdrzve_WL12NP3kBCobppiwYo3Zm_YA6jYm7DrPrUDWfeMsRnATcLHoTTPLrhfR2braINm7HpngOw- Received: from [96.13.233.185] by web34508.mail.mud.yahoo.com via HTTP; Wed, 20 Aug 2008 23:00:07 PDT X-Mailer: YahooMailWebService/0.7.218.2 Date: Wed, 20 Aug 2008 23:00:07 -0700 (PDT) From: gus3 Reply-To: MusicMan529@yahoo.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) To: Szabolcs Szakacsits , Dave Chinner Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20080821051508.GB5706@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <684252.68814.qm@web34508.mail.mud.yahoo.com> X-Barracuda-Connect: web34508.mail.mud.yahoo.com[66.163.178.174] X-Barracuda-Start-Time: 1219298411 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.3268 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: 17648 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs --- On Wed, 8/20/08, Dave Chinner wrote: > Ok, I thought it might be the tiny log, but it didn't > improve anything > here when increased the log size, or the log buffer size. > > Looking at the block trace, I think elevator merging is > somewhat busted. I'm > seeing adjacent I/Os being dispatched without having been > merged. e.g: [snip] > Also, CFQ appears to not be merging WRITE_SYNC bios or > issuing them > with any urgency. The result of this is that it stalls the > XFS > transaction subsystem by capturing all the log buffers in > the > elevator and not issuing them. e.g.: [snip] > The I/Os are merged, but there's still that 700ms delay > before dispatch. > i was looking at this a while back but didn't get to > finishing it off. > i.e.: > > http://oss.sgi.com/archives/xfs/2008-01/msg00151.html > http://oss.sgi.com/archives/xfs/2008-01/msg00152.html > > I'll have a bit more of a look at this w.r.t to > compilebench performance, > because it seems like a similar set of problems that I was > seeing back > then... I concur your observation, esp. w.r.t. XFS and CFQ clashing: http://gus3.typepad.com/i_am_therefore_i_think/2008/07/finding-the-fas.html CFQ is the default on most Linux systems AFAIK; for decent XFS performance one needs to switch to "noop" or "deadline". I wasn't sure if it was broken code, or simply base assumptions in conflict (XFS vs. CFQ). Your log output sheds light on the matter for me, thanks.