Re: xfs-trace-ilock-more

[Dave Chinner <david@fromorbit.com>]

On Wed, Dec 14, 2011 at 02:24:32PM -0500, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/14/2011 01:27 PM, Mark Fasheh wrote:
> > Hey Christoph,
> > 
> > On Tue, Dec 13, 2011 at 09:40:40PM -0500, Christoph Hellwig wrote:
> >> Can you explain the story behid this patch in SLES11SP1?
> > 
> > We were looking at some performance issues and needed a bit more
> > information on the amount of time spent in ilock. I can give you
> > more specifics if you want, I just have to dig up the e-mails (it's
> > been a while).
> 
> That's pretty much the explanation. With heavy reader load, buffered
> writes were stalling for 80 ms and sometimes longer. I suspected it
> was contention on the ilock and the tracing with that patch
> demonstrated a delay there. Since we were chasing a similar issue at
> another site, it seemed worthwhile to just keep it around. We're still
> tracking down the cause. I'm not sure if more recent kernels have the
> same issue as there's been quite a lot of churn.

I'm not surprised - there's nothing really guaranteeing bound shared
vs exclusive access to the ilock. It's all down to the read/write
bias of the rwsem - readers will hold off the writer for some time.
Still, it would be nice to see a trace from such a holdoff to
confirm this is actually the case...

FWIW, if you have an app that requires concurrent, low latency reads
and writes to the same file, that's what the XFS Direct IO was
designed for - in most cases the iolock is taken in shared mode for
both read and write, and so such hold-offs don't generally happen...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs