[Top] [All Lists]

Re: [xfs-masters] linux-next: manual merge of the xfs tree with Linus'

To: Christoph Hellwig <hch@xxxxxx>
Subject: Re: [xfs-masters] linux-next: manual merge of the xfs tree with Linus' tree
From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
Date: Mon, 28 Mar 2011 12:58:09 +0200
Cc: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, David Chinner <david@xxxxxxxxxxxxx>, "xfs-masters@xxxxxxxxxxx" <xfs-masters@xxxxxxxxxxx>, "linux-next@xxxxxxxxxxxxxxx" <linux-next@xxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>
In-reply-to: <20110328105348.GA27458@xxxxxx>
References: <20110328122148.1b48a742.sfr@xxxxxxxxxxxxxxxx> <20110328104753.GA27327@xxxxxx> <20110328105348.GA27458@xxxxxx>
On 2011-03-28 12:53, Christoph Hellwig wrote:
> On Mon, Mar 28, 2011 at 12:47:53PM +0200, Christoph Hellwig wrote:
>> What XFS does is to replace blk_run_address_space, which was a wrapper
>> around blk_run_backing_dev with a direct call to blk_run_backing_dev,
>> as there change means we don't have the address_space around anymore.
>> Jens' tree removes both these functions, and introduces blk_flush_plug
>> as a sort-of replacement.  Sticking to the variant from Jens' tree / mainline
>> with blk_flush_plug is the correct thing here for this case.
>> Where there more conflicts than just this?
> Actually I think we can remove some calls alltogether:  the on-stack
> plugging already flushes the plug queue when context switching,
> which we'll always do in xfs_buf_wait_unpin, and if we get the lock
> without blocking in xfs_buf_lock we don't need to unplug either.

Yes, in fact all of the blk_flush_plug() calls in XFS can just go away
now. I tried to keep them for clarity, but they are primarily there
since XFS was the first conversion/testing I did back when it was hacked

Jens Axboe

<Prev in Thread] Current Thread [Next in Thread>