From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <aelder@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 6/6] xfs: convert xfsbufd to use a workqueue
Date: Fri, 26 Aug 2011 10:18:24 +1000 [thread overview]
Message-ID: <20110826001824.GV3162@dastard> (raw)
In-Reply-To: <20110825234656.GS3162@dastard>
On Fri, Aug 26, 2011 at 09:46:56AM +1000, Dave Chinner wrote:
> On Thu, Aug 25, 2011 at 03:57:19PM -0500, Alex Elder wrote:
> > On Thu, 2011-08-25 at 17:17 +1000, Dave Chinner wrote:
> > > +/*
> > > + * Flush all the queued buffer work, then flush any remaining dirty buffers
> > > + * and wait for them to complete. If there are buffers remaining on the delwri
> > > + * queue, then they were pinned so couldn't be flushed. Return a value of 1 to
> > > + * indicate that there were pinned buffers and the caller needs to retry the
> > > + * flush.
> > > + */
> > > +int
> > > +xfs_flush_buftarg(
> > > + xfs_buftarg_t *target,
> > > + int wait)
> >
> > Since this function now ignores its "wait" argument,
> > you could eliminate it, and perhaps get rid of the
> > one (first) call in xfs_quiesce_fs() that passes 0.
>
> I'll leave that to a another patch.
Actually, I'll re-instate the existing wait semantics here.
In looking at this again I realised there is a race condition in the
flushing code - if work is already in progress, then the wq flush
won't start new work and hence won't see the force flag at all. So
the code needs changing anyway and the only time we need to set the
FORCE_FLUSH flag is when we are supposed to be waiting. Hence I'll
change it back to doing a non-blocking flush when the wait flag is
not set.
If we want to go to just a blocking flush, then we can change
everything in the one patch.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2011-08-26 0:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-25 7:17 [PATCH 0/6] xfs: patch queue for Linux 3.2 Dave Chinner
2011-08-25 7:17 ` [PATCH 1/6] xfs: don't serialise direct IO reads on page cache checks Dave Chinner
2011-08-25 7:17 ` [PATCH 2/6] xfs: don't serialise adjacent concurrent direct IO appending writes Dave Chinner
2011-08-25 21:08 ` Alex Elder
2011-08-26 2:19 ` Dave Chinner
2011-08-25 7:17 ` [PATCH 3/6] xfs: Don't allocate new buffers on every call to _xfs_buf_find Dave Chinner
2011-08-25 20:56 ` Alex Elder
2011-08-25 23:57 ` Dave Chinner
2011-08-25 7:17 ` [PATCH 4/6] xfs: reduce the number of log forces from tail pushing Dave Chinner
2011-08-25 20:57 ` Alex Elder
2011-08-25 23:47 ` Dave Chinner
2011-08-25 7:17 ` [PATCH 5/6] xfs: re-arrange all the xfsbufd delwri queue code Dave Chinner
2011-08-25 20:57 ` Alex Elder
2011-08-25 7:17 ` [PATCH 6/6] xfs: convert xfsbufd to use a workqueue Dave Chinner
2011-08-25 20:57 ` Alex Elder
2011-08-25 23:46 ` Dave Chinner
2011-08-26 0:18 ` Dave Chinner [this message]
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=20110826001824.GV3162@dastard \
--to=david@fromorbit.com \
--cc=aelder@sgi.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox