[Top] [All Lists]

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

To: Peter Leckie <pleckie@xxxxxxx>
Subject: Re: [PATCH v2] Use atomic_t and wait_event to track dquot pincount
From: Mark Goodwin <markgw@xxxxxxx>
Date: Fri, 26 Sep 2008 11:44:07 +1000
Cc: xfs@xxxxxxxxxxx, xfs-dev@xxxxxxx
In-reply-to: <48DC3D13.1010805@xxxxxxx>
Organization: SGI Engineering
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> <48DC3D13.1010805@xxxxxxx>
Reply-to: markgw@xxxxxxx
User-agent: Thunderbird (Windows/20080914)

Peter Leckie wrote:
Lachlan McIlroy wrote:
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.  If
we don't fix the spurious wakeups then we could easily re-introduce this
problem again.  If xfs_qm_dqflush() should be non-blocking then that's a
separate change and it sounds like a good change too.
Ok so what do we want to do. It almost sounds like there are 3 issues I need to solve,
first clean up the code, second make xfs_qm_dqflush() non blocking, and 3ed
fix up the spurious wakeups.

Should I propose 3 patches to fix each of these issues?

yes - can we take the quota fix "as-is" for now. Those of us shipping
NAS servers with quotas enabled need this fix.

The other two issues need more investigation and look like they may have
more fundamental implications - they should be separate bugs.



 Mark Goodwin                                  markgw@xxxxxxx
 Engineering Manager for XFS and PCP    Phone: +61-3-99631937
 SGI Australian Software Group           Cell: +61-4-18969583

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