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: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 24 Sep 2008 10:41:21 -0400
In-reply-to: <20080924074604.GK5448@disturbed>
References: <48D9C1DD.6030607@xxxxxxx> <48D9EB8F.1070104@xxxxxxx> <48D9EF6E.8010505@xxxxxxx> <20080924074604.GK5448@disturbed>
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Sep 24, 2008 at 05:46:04PM +1000, Dave Chinner wrote:
> On Wed, Sep 24, 2008 at 05:42:38PM +1000, Lachlan McIlroy wrote:
> > Looks good Pete.
> 
> No, it is not yet good. Pete cannot explain the underlying problem
> and we need to understand if this is fixing the problem or just
> changing the timing so it doesn't show up....

The patch does not only cause timing but also makes sure
xfs_qm_dqunpin_wait sleeps again when woken up but the condition it was
waiting on is not met.  That's the reason why we have wait_event in
Linux instead of the more traditional sv-style conditional variables.

Now the spurious wakeup from scheduler argument doesn't make any sense,
so this spurious wakeup we're protecting from must come from XFS itself.
The way this could happen is when a task trying to pin the dquot gets
qi_pinlock before the one waiting for q_pincount to reach zero.

So the patch does looks good to me, but the current explanation needs
some updating.


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