From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
Subject: Re: [xfs-masters] xfs deadlock in stable kernel 3.0.4
Date: Thu, 22 Sep 2011 10:14:57 -0400 [thread overview]
Message-ID: <20110922141457.GA11929@infradead.org> (raw)
In-Reply-To: <20110921230718.GS15688@dastard>
On Thu, Sep 22, 2011 at 09:07:18AM +1000, Dave Chinner wrote:
> No, that's not possible. The XFS_AIL_PUSHING_BIT ensures that there
> is only one instance of AIL pushing per struct xfs_ail running at
> once. It's also backed up by the fact that I couldn't find a single
> worker thread blocked running AIL pushing - it ran the 100 item
> scan, got stuck, requeued itself to run again 20ms later....
True, it should prevent that - this was just my only theory based
on the (incorrect) assumption that we'd never get to the log force.
> FYI, what we want the concurrency for in the AIL wq is for multiple
> filesystems to be able to run AIL pushing at the same time, which
> is why it was set up this way. If one filesystem AIL push blocks,
> then an unblocked one will simply run.
A WQ_NON_REENTRANT workqueue will still provide that. From the
documentation:
By default, a wq guarantees non-reentrance only on the same
CPU. A work item may not be executed concurrently on the same
CPU by multiple workers but is allowed to be executed
concurrently on multiple CPUs. This flag makes sure
non-reentrance is enforced across all CPUs. Work items queued
to a non-reentrant wq are guaranteed to be executed by at most
one worker system-wide at any given time.
So this still seems to preferable for the ail workqueue, and should be
able to replace the XFS_AIL_PUSHING_BIT protections.
I also suspect that we should mark the ail workqueue as WQ_MEM_RECLAIM -
a lot of memory reclaim really requires moving the AIL forward.
Currently we have other ways to reclaim inodes, but e.g. for buffers
we rely entirely on AIL pushing, and with the proposed metadata
writeback changes we're going to rely even more on the ail, even if
we still keep emergency synchronous around it's going to be a lot
less efficient than real ail pushing under actual OOM conditions.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-09-22 14:15 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-10 12:23 xfs deadlock in stable kernel 3.0.4 Stefan Priebe
2011-09-12 15:21 ` Christoph Hellwig
2011-09-12 16:46 ` Stefan Priebe
2011-09-12 20:05 ` Christoph Hellwig
2011-09-13 6:04 ` Stefan Priebe - Profihost AG
2011-09-13 19:31 ` Stefan Priebe - Profihost AG
2011-09-13 20:50 ` Christoph Hellwig
2011-09-13 21:52 ` [xfs-masters] " Alex Elder
2011-09-13 21:58 ` Alex Elder
2011-09-13 22:26 ` Christoph Hellwig
2011-09-14 7:26 ` Stefan Priebe - Profihost AG
2011-09-14 7:48 ` Stefan Priebe - Profihost AG
2011-09-14 8:49 ` Stefan Priebe - Profihost AG
2011-09-14 14:30 ` Christoph Hellwig
2011-09-14 14:30 ` Christoph Hellwig
2011-09-14 16:06 ` Stefan Priebe - Profihost AG
2011-09-18 9:14 ` Stefan Priebe - Profihost AG
2011-09-18 20:04 ` Christoph Hellwig
2011-09-19 10:54 ` Stefan Priebe - Profihost AG
2011-09-18 23:02 ` Dave Chinner
2011-09-20 0:47 ` Stefan Priebe
2011-09-20 1:01 ` Stefan Priebe
2011-09-20 10:09 ` Stefan Priebe - Profihost AG
2011-09-20 16:02 ` Christoph Hellwig
2011-09-20 17:23 ` Stefan Priebe - Profihost AG
2011-09-20 17:24 ` Christoph Hellwig
2011-09-20 17:35 ` Stefan Priebe - Profihost AG
2011-09-20 22:30 ` Christoph Hellwig
2011-09-21 2:11 ` [xfs-masters] " Dave Chinner
2011-09-21 7:40 ` Stefan Priebe - Profihost AG
2011-09-21 11:42 ` Dave Chinner
2011-09-21 11:55 ` Stefan Priebe - Profihost AG
2011-09-21 12:26 ` Christoph Hellwig
2011-09-21 13:42 ` Stefan Priebe
2011-09-21 16:48 ` Stefan Priebe - Profihost AG
2011-09-21 17:26 ` Stefan Priebe - Profihost AG
2011-09-21 19:01 ` Stefan Priebe - Profihost AG
2011-09-21 23:07 ` Dave Chinner
2011-09-22 14:14 ` Christoph Hellwig [this message]
2011-09-22 21:49 ` Dave Chinner
2011-09-22 22:01 ` Christoph Hellwig
2011-09-23 5:28 ` Stefan Priebe - Profihost AG
2011-09-22 0:53 ` Dave Chinner
2011-09-22 5:27 ` Stefan Priebe - Profihost AG
2011-09-22 7:52 ` Stefan Priebe - Profihost AG
2011-09-21 7:36 ` Stefan Priebe - Profihost AG
2011-09-21 11:39 ` Christoph Hellwig
2011-09-21 13:39 ` Stefan Priebe
2011-09-21 14:17 ` Christoph Hellwig
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=20110922141457.GA11929@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--cc=s.priebe@profihost.ag \
--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