DBT-2 anticipatory scheduler and filesystem results with 2.6.1

DBT-2 anticipatory scheduler and filesystem results with 2.6.1

[markw]

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 - - markw@osdl.org
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/

Re: DBT-2 anticipatory scheduler and filesystem results with 2.6.1

[Andrew Morton]

markw@osdl.org 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.

Re: DBT-2 anticipatory scheduler and filesystem results with 2.6.1

[Nick Piggin]

Andrew Morton wrote:

>markw@osdl.org 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.

Re: DBT-2 anticipatory scheduler and filesystem results with 2.6.1

[markw]

On 19 Jan, Andrew Morton wrote:
> markw@osdl.org 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

Re: DBT-2 anticipatory scheduler and filesystem results with 2.6.1

[Nick Piggin]

markw@osdl.org wrote:

>On 19 Jan, Andrew Morton wrote:
>
>>markw@osdl.org 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.