Hi Nick,
I ran some dbt-2 tests against 5 filesystems with 2.6.1-mm4 and 2.6.1. I
see a degradation from 0 to 7% in throughput. In most cases there
appears to be a significant difference in the i/o wait and user time
(for PostgreSQL) between 2.6.1 and 2.6.1-mm4, where the i/o wait time is
going up. Thought you might be interested in the results since there
was a tuning patch in 2.6.1-mm3. I have links to more detailed results
(readprofile) here:
http://developer.osdl.org/markw/fs/project_results.html
but here's a summary:
% throughput change from 2.6.1 to 2.6.1-mm4
ext2 -5.9%
ext3 -5.1%
jfs -7.0%
reiserfs -2.2%
xfs -0.3%
--
Mark Wong - - [email protected]
Open Source Development Lab Inc - A non-profit corporation
12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005
(503) 626-2455 x 32 (office)
(503) 626-2436 (fax)
http://developer.osdl.org/markw/
[email protected] wrote:
>
> I ran some dbt-2 tests against 5 filesystems with 2.6.1-mm4 and 2.6.1. I
> see a degradation from 0 to 7% in throughput.
-mm4 also had readahead changes which will adversely impact database-style
workloads. I'd suggest that you revert
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/readahead-revert-lazy-readahead.patch
and retest.
We reverted lazy readahead because it broke NFS linear reads and was doing
the wrong thing anyway. We need to come up with something else for
database-style workloads.
Andrew Morton wrote:
>[email protected] wrote:
>
>> I ran some dbt-2 tests against 5 filesystems with 2.6.1-mm4 and 2.6.1. I
>> see a degradation from 0 to 7% in throughput.
>>
>
>-mm4 also had readahead changes which will adversely impact database-style
>workloads. I'd suggest that you revert
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/readahead-revert-lazy-readahead.patch
>
>and retest.
>
>We reverted lazy readahead because it broke NFS linear reads and was doing
>the wrong thing anyway. We need to come up with something else for
>database-style workloads.
>
>
Oh good. I'd be a bit surprised if it were due to an as-iosched.c change
that
caused the regression.
But there are changes in how new processes are handled, so if you have a lot
of io submitting processes being created, you might see a difference.
On 19 Jan, Andrew Morton wrote:
> [email protected] wrote:
>>
>> I ran some dbt-2 tests against 5 filesystems with 2.6.1-mm4 and 2.6.1. I
>> see a degradation from 0 to 7% in throughput.
>
> -mm4 also had readahead changes which will adversely impact database-style
> workloads. I'd suggest that you revert
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/readahead-revert-lazy-readahead.patch
>
> and retest.
>
> We reverted lazy readahead because it broke NFS linear reads and was doing
> the wrong thing anyway. We need to come up with something else for
> database-style workloads.
Ok, ran through a set of tests a -R of the
readahead-revert-lazy-readahead.patch. Saw a significant improvement
with xfs, but the other file systems appeared to improve only marginally
compared to 2.6.1-mm4 with that patch.
Here's a summary compared to 2.6.1:
% throughput change from 2.6.1 to 2.6.1-mm4 -R readahead
ext2 -4.9
ext3 -4.3
jfs -5.1
reiserfs -3.8
xfs 14.8
Here's the summary of the original 2.6.1-mm4 for reference:
% throughput change from 2.6.1 to 2.6.1-mm4
ext2 -5.9%
ext3 -5.1%
jfs -7.0%
reiserfs -2.2%
xfs -0.3%
And the link to the result details:
http://developer.osdl.org/markw/fs/project_results.html
[email protected] wrote:
>On 19 Jan, Andrew Morton wrote:
>
>>[email protected] wrote:
>>
>>> I ran some dbt-2 tests against 5 filesystems with 2.6.1-mm4 and 2.6.1. I
>>> see a degradation from 0 to 7% in throughput.
>>>
>>-mm4 also had readahead changes which will adversely impact database-style
>>workloads. I'd suggest that you revert
>>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/readahead-revert-lazy-readahead.patch
>>
>>and retest.
>>
>>We reverted lazy readahead because it broke NFS linear reads and was doing
>>the wrong thing anyway. We need to come up with something else for
>>database-style workloads.
>>
>
>Ok, ran through a set of tests a -R of the
>readahead-revert-lazy-readahead.patch. Saw a significant improvement
>with xfs, but the other file systems appeared to improve only marginally
>compared to 2.6.1-mm4 with that patch.
>
>Here's a summary compared to 2.6.1:
>
> % throughput change from 2.6.1 to 2.6.1-mm4 -R readahead
>ext2 -4.9
>ext3 -4.3
>jfs -5.1
>reiserfs -3.8
>xfs 14.8
>
>Here's the summary of the original 2.6.1-mm4 for reference:
>
> % throughput change from 2.6.1 to 2.6.1-mm4
>ext2 -5.9%
>ext3 -5.1%
>jfs -7.0%
>reiserfs -2.2%
>xfs -0.3%
>
Thanks Mark.
Thats better but still not great. I have a test case from Nigel
Cunningham that performs very badly with AS. I'll try to get
that fixed up first and it might improve your case.
There are other things in mm that might change your results, not
least of which being the new SMP scheduler work.