Quantcast

Re: [RFC, PATCH 0/7] XFS: dynamic busy extent tracking

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC, PATCH 0/7] XFS: dynamic busy extent tracking

Martin Steigerwald

Hi Dave,

Am Mittwoch 08 Oktober 2008 schrieb Dave Chinner:
> The busy extent tracking in XFS is currently very static and has
> some performance issues. We can only track 128 busy extents per AG,
> and when we overflow this we fall back to synchronous transactions.
> Also, every time we re-use a busy extent we cause a synchronous log
> force, which stops all allocation and freeing in that AG while the
> log force is in progress.

Could this accelerate

tar -xf linux-2.6.26.tar.gz
rm -r linux-2.6.26

?

A student in the Linux Performance Tuning course I hold this week compared
this with ext3, even with the improved mkfs.xfs options (but without
lazy-count=1, cause mkfs.xfs from Debian Etch is too old) and even with
noop as IO scheduler. AFAIR XFS took roughly 3-4 times as long as Ext3, I
did not note the exact numbers. This was with 2.6.25. I can repeat the
test locally with 2.6.26.5 if wanted.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC, PATCH 0/7] XFS: dynamic busy extent tracking

Dave Chinner
On Thu, Oct 09, 2008 at 08:17:32PM +0200, Martin Steigerwald wrote:

>
> Hi Dave,
>
> Am Mittwoch 08 Oktober 2008 schrieb Dave Chinner:
> > The busy extent tracking in XFS is currently very static and has
> > some performance issues. We can only track 128 busy extents per AG,
> > and when we overflow this we fall back to synchronous transactions.
> > Also, every time we re-use a busy extent we cause a synchronous log
> > force, which stops all allocation and freeing in that AG while the
> > log force is in progress.
>
> Could this accelerate
>
> tar -xf linux-2.6.26.tar.gz
> rm -r linux-2.6.26

Not really. There is very little reuse of freed extents in this
type of workload. It's when you have 10 users on the filesystem
all doing that sort of thing that it will make a difference.

> ?
>
> A student in the Linux Performance Tuning course I hold this week compared
> this with ext3, even with the improved mkfs.xfs options (but without
> lazy-count=1, cause mkfs.xfs from Debian Etch is too old) and even with
> noop as IO scheduler. AFAIR XFS took roughly 3-4 times as long as Ext3, I
> did not note the exact numbers. This was with 2.6.25. I can repeat the
> test locally with 2.6.26.5 if wanted.

Yes, that's par for the course. XFS journals transactions almost
immediately, whereas ext3 gathers lots of changees in memory and
checkpoints infrequently. Hence XFS writes a lot more to the
journal and is hence slower. The dynamic extent tracking is a
necessary step to moving the XFS journalling to a more
checkpoint-like setup which would perform much less journal
I/O and hence run substantially faster....

See the asynchronous transaction aggregation section here:

http://xfs.org/index.php/Improving_Metadata_Performance_By_Reducing_Journal_Overhead

Cheers,

Dave.
--
Dave Chinner
[hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC, PATCH 0/7] XFS: dynamic busy extent tracking

Martin Steigerwald
Am Freitag 10 Oktober 2008 schrieben Sie:
> On Thu, Oct 09, 2008 at 08:17:32PM +0200, Martin Steigerwald wrote:
> > Hi Dave,

[...]

> > A student in the Linux Performance Tuning course I hold this week
> > compared this with ext3, even with the improved mkfs.xfs options (but
> > without lazy-count=1, cause mkfs.xfs from Debian Etch is too old) and
> > even with noop as IO scheduler. AFAIR XFS took roughly 3-4 times as
> > long as Ext3, I did not note the exact numbers. This was with 2.6.25.
> > I can repeat the test locally with 2.6.26.5 if wanted.
>
> Yes, that's par for the course. XFS journals transactions almost
> immediately, whereas ext3 gathers lots of changees in memory and
> checkpoints infrequently. Hence XFS writes a lot more to the
> journal and is hence slower. The dynamic extent tracking is a
> necessary step to moving the XFS journalling to a more
> checkpoint-like setup which would perform much less journal
> I/O and hence run substantially faster....
>
> See the asynchronous transaction aggregation section here:
>
> http://xfs.org/index.php/Improving_Metadata_Performance_By_Reducing_Jou
>rnal_Overhead

Thanks for the info Dave.

I still have your three mails about future improvements on XFS on my
reading list. I just read a bit of the first one.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


Loading...