xfs
[Top] [All Lists]

Re: XFS: Abysmal write performance because of excessive seeking (allocat

To: Linux fs XFS <xfs@xxxxxxxxxxx>
Subject: Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?)
From: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Fri, 6 Apr 2012 01:13:36 +0100
In-reply-to: <20350.9643.379841.771496@xxxxxxxxxxxxxxxxxx>
References: <CAAxjCEwBMbd0x7WQmFELM8JyFu6Kv_b+KDe3XFqJE6shfSAfyQ@xxxxxxxxxxxxxx> <20350.9643.379841.771496@xxxxxxxxxxxxxxxxxx>
[ ... ]

> Which means that your Linux-level seek graphs may be not so
> useful, because the host adapter may be drastically rearranging
> the seek patterns, and you may need to tweak the P400 elevator,
> rather than or in addition to the Linux elevator.

> Unless possibly barriers are enabled, and even with a BBWC the
> P400 writes through on receiving a barrier request. IIRC XFS is
> rather stricter in issuing barrier requests than 'ext4', and you
> may be seeing more the effect of that than the effect of aiming
> to splitting the access patterns between 4 AGs [ ... ]

As to this, in theory even having split the files among 4 AGs,
the upload from system RAM to host adapter RAM and then to disk
could happen by writing first all the dirty blocks for one AG,
then a long seek to the next AG, and so on, and the additional
cost of 3 long seeks would be negligible. 

That you report a significant slowdown indicates that this is
not happening, and that likely XFS flushing is happening not in
spacewise order but in timewise order.

The seeks graphs you have gathered indeed indicate that with
'ext4' there is a spacewise flush, while with XFS the flush
alternates constantly among the 4 AGs, instead of doing each AG
in turn. Which seems to indicate an elevator issue or a barrier
issue after the delayed allocator has assigned block addresses
to the various pages being flushed.

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