xfs
[Top] [All Lists]

Re: [PATCH 02/27] xfs: re-enable non-blocking behaviour in xfs_map_block

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 02/27] xfs: re-enable non-blocking behaviour in xfs_map_blocks
From: Alex Elder <aelder@xxxxxxx>
Date: Wed, 6 Jul 2011 08:36:01 -0500
Cc: <xfs@xxxxxxxxxxx>
In-reply-to: <20110706063700.GA4508@xxxxxxxxxxxxx>
References: <20110701094321.936534538@xxxxxxxxxxxxxxxxxxxxxx> <20110701094602.465074143@xxxxxxxxxxxxxxxxxxxxxx> <1309905319.1950.48.camel@doink> <20110706063700.GA4508@xxxxxxxxxxxxx>
Reply-to: <aelder@xxxxxxx>
On Wed, 2011-07-06 at 02:37 -0400, Christoph Hellwig wrote:
> On Tue, Jul 05, 2011 at 05:35:19PM -0500, Alex Elder wrote:
> > On Fri, 2011-07-01 at 05:43 -0400, Christoph Hellwig wrote:
> > > The non-blockig behaviour in xfs_map_blocks currently is conditional on
> > > having both the WB_SYNC_NONE sync_mode and the nonblocking flag set.
> > > The latter used to be used by both pdflush, kswapd and a few other places
> > > in older kernels, but has been fading out starting with the introduction
> > > of the per-bdi flusher threads.
> > > 
> > > Enable the non-blocking behaviour for all WB_SYNC_NONE calls to get back
> > > the behaviour we want.
> > 
> > The subject line should refer to xfs_vm_writepage()
> > (not xfs_map_blocks()).  Unless I hear otherwise I
> > will plan to change that for you.
> 
> Well, the actual xfs_ilock_nowait call is in xfs_map_blocks, the logic
> controlling it in xfs_vm_writepage, so either one is fine.

You're right.  Nevermind.       -Alex

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