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@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
