Re: [PATCH 16/26] xfs: synchronous AIL pushing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 11, 2019 at 03:18:25AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 09, 2019 at 02:21:14PM +1100, Dave Chinner wrote:
> > Factor the common AIL deletion code that does all the wakeups into a
> > helper so we only have one copy of this somewhat tricky code to
> > interface with all the wakeups necessary when the LSN of the log
> > tail changes.
> > 
> > xfs_ail_push_sync() is temporary infrastructure to facilitate
> > non-blocking, IO-less inode reclaim throttling that allows further
> > structural changes to be made. Once those structural changes are
> > made, the need for this function goes away and it is removed,
> > leaving us with only the xfs_ail_update_finish() factoring when this
> > is all done.
> 
> The xfs_ail_update_finish work here is in an earlier patch, so the
> changelog will need some updates.
> 
> > +	spin_lock(&ailp->ail_lock);
> > +	while ((lip = xfs_ail_min(ailp)) != NULL) {
> > +		prepare_to_wait(&ailp->ail_push, &wait, TASK_UNINTERRUPTIBLE);
> > +		if (XFS_FORCED_SHUTDOWN(ailp->ail_mount) ||
> > +		    XFS_LSN_CMP(threshold_lsn, lip->li_lsn) <= 0)

Wasn't this supposed to change to < 0? The rfc series had that logic,
but it changed from <= to < later in the wrong patch.

> > +			break;
> > +		/* XXX: cmpxchg? */
> > +		while (XFS_LSN_CMP(threshold_lsn, ailp->ail_target) > 0)
> > +			xfs_trans_ail_copy_lsn(ailp, &ailp->ail_target, &threshold_lsn);
> 
> This code looks broken on 32-bit given that xfs_trans_ail_copy_lsn takes
> the ail_lock there.  Just replacing the xfs_trans_ail_copy_lsn call with
> a direct assignment would fix that, no need for cmpxchg either as far
> as I can tell (and it would fix that too long line as well).
> 
> But a:
> 
> 		while (XFS_LSN_CMP(threshold_lsn, ailp->ail_target) > 0)
> 			ailp->ail_target = threshold_lsn;
> 
> still looks odd, I think this should simply be an if. 
> 
> > +		wake_up_process(ailp->ail_task);
> > +		spin_unlock(&ailp->ail_lock);
> 
> xfsaild will take ail_lock pretty quickly.  I think we should drop
> the lock before waking it.

Can't we replace this whole thing with something that repurposes
xfs_ail_push_all_sync()? That only requires some tweaks to the existing
function and the new _push_all_sync() wrapper ends up looking something
like:

	while ((threshold_lsn = xfs_ail_max_lsn(ailp)) != 0)
		xfs_ail_push_sync(ailp, threshold_lsn);

There's an extra lock cycle, but that's still only on tail updates. That
doesn't seem unreasonable to me for the usage of _push_all_sync().

Brian




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux