Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 04:20:47 -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.3 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 m5QBKfDX005686 for ; Thu, 26 Jun 2008 04:20:41 -0700 X-ASG-Debug-ID: 1214479299-5e5801e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 15498286E1F for ; Thu, 26 Jun 2008 04:21:40 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id ipdNIdDVGiY2LjG7 for ; Thu, 26 Jun 2008 04:21:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGANexXkh5LG+uZWdsb2JhbACSahICHpsi X-IronPort-AV: E=Sophos;i="4.27,708,1204464600"; d="scan'208";a="143488518" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail04.adl2.internode.on.net with ESMTP; 26 Jun 2008 20:51:35 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBpXh-0004Ww-Tk; Thu, 26 Jun 2008 21:21:33 +1000 Date: Thu, 26 Jun 2008 21:21:33 +1000 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626112133.GJ11558@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626074636.GB7064@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626074636.GB7064@infradead.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214479302 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.1, rules version 3.1.54384 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16565 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, Jun 26, 2008 at 03:46:36AM -0400, Christoph Hellwig wrote: > On Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote: > > XFS object flushing doesn't quite match existing completion semantics. It > > mixed exclusive access with completion. That is, we need to mark an object as > > being flushed before flushing it to disk, and then block any other attempt to > > flush it until the completion occurs. > > > > To do this we introduce: > > > > void init_completion_flush(struct completion *x) > > which initialises x->done = 1 > > > > void completion_flush_start(struct completion *x) > > which blocks if done == 0, otherwise decrements done to zero and > > allows the caller to continue. > > > > bool completion_flush_start_nowait(struct completion *x) > > returns a failure status if done == 0, otherwise decrements done > > to zero and returns a "flush started" status. This is provided > > to allow flushing to begin safely while holding object locks in > > inverted order. > > > > This replaces the use of semaphores for providing this exclusion > > and completion mechanism. > > Given that the only API call shared with normal completions is > complete() I'd rather make this a primitive of it's own, even if > internally implemented as completions. Ok, so that involves exactly what? A new header file, a new API name (ideas anyone?) and kerneldoc comments? Cheers, Dave. -- Dave Chinner david@fromorbit.com