All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Brian Foster <bfoster@redhat.com>, xfs@oss.sgi.com
Subject: Re: [PATCH v3] xfs: re-enable xfsaild idle mode and fix associated races
Date: Mon, 2 Jul 2012 18:29:52 +1000	[thread overview]
Message-ID: <20120702082952.GR19223@dastard> (raw)
In-Reply-To: <20120702070502.GA25568@infradead.org>

On Mon, Jul 02, 2012 at 03:05:02AM -0400, Christoph Hellwig wrote:
> >  			__set_current_state(TASK_KILLABLE);
> >  		else
> >  			__set_current_state(TASK_INTERRUPTIBLE);
> > -		schedule_timeout(tout ?
> > -				 msecs_to_jiffies(tout) : MAX_SCHEDULE_TIMEOUT);
> > +
> > +		spin_lock(&ailp->xa_lock);
> > +
> > +		/*
> > +		 * Idle if the AIL is empty and we are not racing with a target
> > +		 * update. We check the AIL after we set the task to a sleep
> > +		 * state to guarantee that we either catch an xa_target update
> > +		 * or that a wake_up resets the state to TASK_RUNNING.
> > +		 * Otherwise, we run the risk of sleeping indefinitely.
> > +		 *
> > +		 * The barrier matches the xa_target update in xfs_ail_push().
> > +		 */
> > +		smp_rmb();
> > +		if (!xfs_ail_min(ailp) &&
> > +		    ailp->xa_target == ailp->xa_target_prev) {
> > +			spin_unlock(&ailp->xa_lock);
> > +			schedule();
> > +			tout = 0;
> > +			continue;
> > +		}
> 
> I still don't like this at all all - we have one place to do all the
> timeout decisions, and that is and then end of xfsaild_push.  Splitting
> this decision over two functions makes the code a lot harder to
> understand and maintain over the long run.

The timeout decision is separate to idling, though - the idle check
has to be done when we are already in
TASK_INTERRUPTIBLE/TASK_KILLABLE state. If we do the check before
changing the task state, we can miss wakeups when the target is
changed between the "are we really idle" check and the schedule()
call because the wakeup is ignored if the task is still in the
running state.

> That doesn't mean I don't like the algorithm behind this patch, it just
> needs to move into the right place.

I'm not sure it can be moved into xfsaild_push and still be nice and
clean because of the above requirement...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-07-02  8:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 10:52 [PATCH v3] xfs: re-enable xfsaild idle mode and fix associated races Brian Foster
2012-07-02  0:07 ` Dave Chinner
2012-07-02 13:33   ` Brian Foster
2012-07-02 23:51     ` Dave Chinner
2012-07-03 13:13       ` Brian Foster
2012-07-03 16:07         ` Christoph Hellwig
2012-07-02  7:05 ` Christoph Hellwig
2012-07-02  8:29   ` Dave Chinner [this message]
2012-07-02 13:51     ` Brian Foster
2012-07-17  7:00       ` Christoph Hellwig
2012-07-24 13:22         ` Christoph Hellwig
2012-07-24 14:54           ` Ben Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120702082952.GR19223@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.