xfs
[Top] [All Lists]

Re: [PATCH v2] Use atomic_t and wait_event to track dquot pincount

To: Lachlan McIlroy <lachlan@xxxxxxx>, Peter Leckie <pleckie@xxxxxxx>, xfs@xxxxxxxxxxx, xfs-dev@xxxxxxx
Subject: Re: [PATCH v2] Use atomic_t and wait_event to track dquot pincount
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Fri, 26 Sep 2008 13:38:45 +1000
In-reply-to: <20080926025718.GJ27997@disturbed>
References: <48D9C1DD.6030607@xxxxxxx> <48D9EB8F.1070104@xxxxxxx> <48D9EF6E.8010505@xxxxxxx> <20080924074604.GK5448@disturbed> <48D9F718.4010905@xxxxxxx> <20080925010318.GB27997@disturbed> <48DB4F3F.8040307@xxxxxxx> <20080926003401.GG27997@disturbed> <48DC3BBB.4080807@xxxxxxx> <20080926025718.GJ27997@disturbed>
Reply-to: lachlan@xxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080707)
Dave Chinner wrote:
On Fri, Sep 26, 2008 at 11:32:43AM +1000, Lachlan McIlroy wrote:
Dave Chinner wrote:
On Thu, Sep 25, 2008 at 06:43:43PM +1000, Peter Leckie wrote:
However xfssyncd has had a long history of the task being woken up from other code, so it looks like it's simply not safe for either the aild or xfssyncd to sleep on a queue assuming that
no one else will wake the processes up.
Given that both xfsaild and xfssyncd are supposed to be doing
non-blocking flushes, neither of them should ever be waiting on a
pinned item, therefore fixing that problem in xfs_qm_dqflush()
should make this problem go away. It will also substantially
reduce tehnumber of log forces being triggered by dquot writeback
which will have positive impact on performance, too.

So I would say the fix I proposed is a good solution for this issue.
but it doesn't fix the underlying problem that was causing the
spurious wakeups, which is the fact that xfs_qm_dqflush() is not
obeying non-blocking flush directions.
The underlying problem has nothing to do with xfs_qm_dqflush() - the
spurious wakeups are caused by calls to wake_up_process() that arbitrarily
wake up a process that is in a state where it shouldn't be woken up.

Spurious wakeups are causing problems in a place where we should not even be sleeping. If you don't sleep there, you can't get spurious
wakeups....

If we don't fix the spurious wakeups then we could easily re-introduce this
problem again.

Right, but keep in mind that the patch doesn't prevent spurious
wakeups - it merely causes the thread to wakeup and go back to sleep
Yes that's right and it's why I suggested replacing the uses of wake_up_process
with wake_up and a wait queue where both the xfsaild and xfssyncd threads can
have a wait queue specific to them.  This way we only wake them up if they are
sleeping on that wait queue and not somewhere else waiting for a different 
event.
I'm pretty sure that will be a safe change to make.

when a spurious wakeup occurs. The patch I posted avoids the
spurious wakeup problem completely, which is what we should be
aiming to do given it avoids the overhead of 2 context switches
and speeds up the rate at which we can flush unpinned dquots.

That being said, I agree that the original patch is still desirable,
though not from a bug-fix perspective. It's a cleanup and
optimisation patch, with the nice side effect of preventing future
occurrences of the spurious wakeup problem....

Cheers,

Dave.

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