[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <492C466A.7070200@msgid.tls.msk.ru>
Date: Tue, 25 Nov 2008 21:39:38 +0300
From: Michael Tokarev <mjt@....msk.ru>
To: Justin Piszcz <jpiszcz@...idpixels.com>
CC: Eric Sandeen <sandeen@...deen.net>,
Stian Jordet <liste@...det.net>, linux-kernel@...r.kernel.org,
xfs@....sgi.com, Alan Piszcz <ap@...arrain.com>
Subject: Re: Extreme slowness with xfs [WAS: Re: Slowness with new pc]
Justin Piszcz wrote:
[]
> barriers enabled:
> real 2m40.643s
> barriers disabled:
> real 0m27.612s
Barriers enabled:
$ time sh -c "tar xf linux-2.6.27.tar.bz2; sync"
real 2m3.317s
user 0m33.990s
sys 0m3.980s
$ time sh -c "rm -rf linux-2.6.27; sync"
real 1m4.033s
user 0m0.080s
sys 0m2.860s
Barriers disabled:
$ time sh -c "tar xf linux-2.6.27.tar.bz2; sync"
real 0m36.279s
user 0m25.610s
sys 0m2.800s
$ time sh -c "rm -rf linux-2.6.27; sync"
real 0m3.694s
user 0m0.010s
sys 0m2.230s
During unpack, with barriers=on, the cpu usage stays
hardy noticeable, while with barriers=off, the thing
becomes CPU-bound (needed for bzip2).
For comparison, here are results for jfs on the
same drive:
$ time sh -c "tar xf /stage/build/kernel/linux-2.6.27.tar.bz2; sync"
real 0m36.062s
user 0m25.370s
sys 0m2.860s
$ time sh -c "rm -rf linux-2.6.27; sync"
real 0m3.024s
user 0m0.040s
sys 0m0.750s
This jfs partition is located a bit further on the same disk,
so raw speed of it is a bit lower. Yet the numbers are pretty
similar. In any case, xfs with barriers is MUCH worse...
The disk is a 500Gig Hitachi HUA72105 one ("raid edition"),
on an AMD 780g/SB700 chipset in ahci mode.
/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists