Skip to contentSkip to conversation

DBT-2 anticipatory scheduler and filesystem results with 2.6.1

DISCUSSION [email protected] 3 participants 5 messages Jan 20, 2004 – Jan 22, 2004

lore
Share & tools
lore

[email protected]

author
#0 lore raw

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%

Signature · 6 lines
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/
#1 lore raw
Quoted 3 lines · [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.

#2 lore raw
Quoted 9 lines · Andrew Morton
Quoted 3 lines · [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

Quoted 9 lines

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.

author
#3 lore raw
In reply to Andrew Morton
Quoted 8 lines · Andrew Morton
Quoted 3 lines · [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

Quoted 7 lines

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

#4 lore raw
Quoted 33 lines · [email protected] wrote:
Quoted 8 lines · Andrew Morton
Quoted 3 lines · [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

Quoted 8 lines

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

Quoted 9 lines

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.