xfs
[Top] [All Lists]

Re: [PATCH 3/4] xfs: revert to using a kthread for AIL pushing

To: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH 3/4] xfs: revert to using a kthread for AIL pushing
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 10 Oct 2011 09:26:11 -0400
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, xfs@xxxxxxxxxxx, Stefan Priebe <s.priebe@xxxxxxxxxxxx>
In-reply-to: <20111010055546.GA1641@xxxxxxxxxxxxxx>
References: <20111006183257.036884724@xxxxxxxxxxxxxxxxxxxxxx> <20111006183549.770414484@xxxxxxxxxxxxxxxxxxxxxx> <20111010014509.GT3159@dastard> <20111010055546.GA1641@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Oct 10, 2011 at 07:55:46AM +0200, Markus Trippelsdorf wrote:
> Wouldn't it be possible to verify that the problem also goes away with
> this simple one liner?

We've been through a few variants, and none fixed it while Stefan had
to try them on production machines.

To be honest I'm not convinced at all that a workqueue was such a good
idea for the ail in particular.  It works extremly well for things were
we can easily define a work item, e.g. an object that gets queued up
and a method on it gets exectured.  But for the AIL we really have
a changing target that needs more or less constant pushing, and the
target keeps changing while executing our work.  Conceptually it fits
the idea of an thread much better, with the added benefit of not relying
on finding a combination of workqueue flags that gets the exact
behaviour (exectuion ASAP without any limits because of other items
or required memory allocation).

And unlike the various per-cpu threads we used to have it is only one
thread per filesystem anyway.

<Prev in Thread] Current Thread [Next in Thread>