xfs
[Top] [All Lists]

Re: [PATCH] Re: XFS performance oddity

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] Re: XFS performance oddity
From: Nick Piggin <npiggin@xxxxxxxxx>
Date: Thu, 25 Nov 2010 15:54:24 +1100
Cc: Nick Piggin <npiggin@xxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20101124052823.GD22876@dastard>
References: <20101123122449.GA4812@amd> <20101123205804.GX22876@dastard> <20101124005003.GB3168@amd> <20101124031524.GC22876@dastard> <20101124052823.GD22876@dastard>
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Nov 24, 2010 at 04:28:23PM +1100, Dave Chinner wrote:
> xfs: push stale, pinned buffers on trylock failures
> 
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> 
> As reported by Nick Piggin, XFS is suffering from long pauses under
> highly concurrent workloads when hosted on ramdisks. The problem is
> that an inode buffer is stuck in the pinned state in memory and as a
> result either the inode buffer or one of the inodes within the
> buffer is stopping the tail of the log from being moved forward.
> 
> The system remains in this state until a periodic log force issued
> by xfssyncd causes the buffer to be unpinned. The main problem is
> that these are stale buffers, and are hence held locked until the
> transaction/checkpoint that marked them state has been committed to
> disk. When the filesystem gets into this state, only the xfssyncd
> can cause the async transactions to be committed to disk and hence
> unpin the inode buffer.
> 
> This problem was encountered when scaling the busy extent list, but
> only the blocking lock interface was fixed to solve the problem.
> Extend the same fix to the buffer trylock operations - if we fail to
> lock a pinned, stale buffer, then force the log immediately so that
> when the next attempt to lock it comes around, it will have been
> unpinned.
> 
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>

No more stalls, thanks.

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