2.4.1pre8 slowdown on dbench tests

2.4.1pre8 slowdown on dbench tests

[Marcelo Tosatti]

Hi, 

On my dbench runs I've noted a slowdown between pre4 and pre8 with 48
threads. (128MB, 2 CPU's machine)

pre4: 
Throughput 7.05841 MB/sec (NB=8.82301 MB/sec 70.5841 MBit/sec)
70.94user 232.54system 15:17.39elapsed 33%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (1277major+1586minor)pagefaults 0swaps

pre8: 
Throughput 6.11383 MB/sec (NB=7.64229 MB/sec 61.1383 MBit/sec)
70.67user 184.18system 17:38.98elapsed 24%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (1277major+1586minor)pagefaults 0swaps


There have been no VM changes between pre4 and pre8. 

Jens, can be the -blk patch the reason for the slowdown I'm seeing?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Szabolcs Szakacsits]

On Thu, 18 Jan 2001, Marcelo Tosatti wrote:

> On my dbench runs I've noted a slowdown between pre4 and pre8 with 48
> threads. (128MB, 2 CPU's machine)

Below some kernel compile numbers on a 32 MB RAM + 32 MB swap box. The
three lines mean compilation with the -j1, -j2 and -j4 option. Most of
the time 2.4.1pre8 was also unable to compile the kernel because cc1
was killed by OOM handler.

	Szaka

2.2.18
548.27user 94.18system     10:50  98%CPU (450479major+696869minor)
548.94user 153.85system    11:51  98%CPU (487111major+704948minor)
599.44user 2018.66system   51:47  84%CPU (2295045major+1182819minor)
=========
2.4.0
557.18user 121.57system    11:25  99%CPU (442434major+705429minor)
551.76user 158.78system    12:11  97%CPU (446183major+711572minor)
579.65user 2860.53system 1:05:45  87%CPU (650964major+1209969minor)
===========
2.4.0+blk-13B
546.89user 140.35system    11:33  99%CPU (442435major+705424minor)
570.73user 188.51system    12:56  97%CPU (445171major+712791minor)
566.33user 2681.20system 1:02:26  86%CPU (654402major+1225784minor)
=================
2.4.1pre8
546.23user 118.81system    11:09  99%CPU (442434major+705424minor)
569.12user 161.25system    12:22  98%CPU (446667major+712457minor)
727.58user 2489.96system 1:25:34  62%CPU (616240major+1375321minor)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Szabolcs Szakacsits]

Redone with big enough swap by requests.

2.4.0,132MB swap
548.81user 128.97system    11:22  99%CPU (442433major+705419minor)
561.12user 171.06system    12:29  97%CPU (446949major+712525minor)
625.68user 2833.29system 1:12:38  79%CPU (638957major+1463974minor)
===========
2.4.1pre8,132MB swap
548.71user 117.93system    11:09  99%CPU (442434major+705420minor)
558.93user 166.82system    12:20  98%CPU (446941major+712662minor)
621.37user 2592.54system 1:07:33  79%CPU (592679major+1311442minor)

> Below some kernel compile numbers on a 32 MB RAM + 32 MB swap box. The
> three lines mean compilation with the -j1, -j2 and -j4 option. Most of
> the time 2.4.1pre8 was also unable to compile the kernel because cc1
> was killed by OOM handler.
>
> 2.2.18
> 548.27user 94.18system     10:50  98%CPU (450479major+696869minor)
> 548.94user 153.85system    11:51  98%CPU (487111major+704948minor)
> 599.44user 2018.66system   51:47  84%CPU (2295045major+1182819minor)
> =========
> 2.4.0
> 557.18user 121.57system    11:25  99%CPU (442434major+705429minor)
> 551.76user 158.78system    12:11  97%CPU (446183major+711572minor)
> 579.65user 2860.53system 1:05:45  87%CPU (650964major+1209969minor)
> ===========
> 2.4.0+blk-13B
> 546.89user 140.35system    11:33  99%CPU (442435major+705424minor)
> 570.73user 188.51system    12:56  97%CPU (445171major+712791minor)
> 566.33user 2681.20system 1:02:26  86%CPU (654402major+1225784minor)
> =================
> 2.4.1pre8
> 546.23user 118.81system    11:09  99%CPU (442434major+705424minor)
> 569.12user 161.25system    12:22  98%CPU (446667major+712457minor)
> 727.58user 2489.96system 1:25:34  62%CPU (616240major+1375321minor)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Fri, Jan 19 2001, Szabolcs Szakacsits wrote:
> 
> Redone with big enough swap by requests.
> 
> 2.4.0,132MB swap
> 548.81user 128.97system    11:22  99%CPU (442433major+705419minor)
> 561.12user 171.06system    12:29  97%CPU (446949major+712525minor)
> 625.68user 2833.29system 1:12:38  79%CPU (638957major+1463974minor)
> ===========
> 2.4.1pre8,132MB swap
> 548.71user 117.93system    11:09  99%CPU (442434major+705420minor)
> 558.93user 166.82system    12:20  98%CPU (446941major+712662minor)
> 621.37user 2592.54system 1:07:33  79%CPU (592679major+1311442minor)

Better, could you try with the number changes that Andrea suggested
too? Thanks.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Szabolcs Szakacsits]

On Fri, 19 Jan 2001, Jens Axboe wrote:
> On Fri, Jan 19 2001, Szabolcs Szakacsits wrote:
> > Redone with big enough swap by requests.
> > 2.4.0,132MB swap
> > 548.81user 128.97system    11:22  99%CPU (442433major+705419minor)
> > 561.12user 171.06system    12:29  97%CPU (446949major+712525minor)
> > 625.68user 2833.29system 1:12:38  79%CPU (638957major+1463974minor)
> > ===========
> > 2.4.1pre8,132MB swap
> > 548.71user 117.93system    11:09  99%CPU (442434major+705420minor)
> > 558.93user 166.82system    12:20  98%CPU (446941major+712662minor)
> > 621.37user 2592.54system 1:07:33  79%CPU (592679major+1311442minor)
>
> Better, could you try with the number changes that Andrea suggested
> too? Thanks.

Helped intensive swapping a bit, degraded other cases [no or slight
swapping].

2.4.1pre8,32MB RAM,132MB swap,blk suggestion
544.19user 141.25system    11:31  99%CPU (442419major+705411minor)
554.83user 191.57system    12:41  98%CPU (445762major+710409minor)
612.05user 2551.37system 1:07:21  78%CPU (589623major+1313665minor)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Andrea Arcangeli]

On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
> Jens, can be the -blk patch the reason for the slowdown I'm seeing?

This heuristic is way too aggressive:

	/*
	 * Try to keep 128MB max hysteris. If not possible,
	 * use half of RAM
	 */
	high_queued_sectors = (total_ram * 2) / 3;
	low_queued_sectors = high_queued_sectors - MB(128);
	if (low_queued_sectors < 0)
		low_queued_sectors = total_ram / 2;

	/*
	 * for big RAM machines (>= 384MB), use more for I/O
	 */
	if (total_ram >= MB(384)) {
		high_queued_sectors = (total_ram * 4) / 5;
		low_queued_sectors = high_queued_sectors - MB(128);
	}

2/3 of ram locked down in the I/O queue is way too much. 1/3 should be ok. big
RAM machines needs way less than 1/3 locked down.

Marcelo can you give a try with `high_queued_sectors = total_ram / 3' and
low_queued_sectors = high_queued_sectors / 2 and drop the big ram machine
check?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Marcelo Tosatti]

On Fri, 19 Jan 2001, Andrea Arcangeli wrote:

> Marcelo can you give a try with `high_queued_sectors = total_ram / 3' and
> low_queued_sectors = high_queued_sectors / 2 and drop the big ram machine
> check?

Andrea,

With the changes you suggested I got almost the same results with
pre8. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Thu, Jan 18 2001, Marcelo Tosatti wrote:
> > Marcelo can you give a try with `high_queued_sectors = total_ram / 3' and
> > low_queued_sectors = high_queued_sectors / 2 and drop the big ram machine
> > check?
> 
> Andrea,
> 
> With the changes you suggested I got almost the same results with
> pre8. 

Good, so it's getting closer. Actually, the dbench numbers being
this close (or better) is only due to blk-xx optimizations. The
latency is much smaller, which usually really hurts dbench quite
a bit in testing.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Fri, Jan 19 2001, Andrea Arcangeli wrote:
> On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
> > Jens, can be the -blk patch the reason for the slowdown I'm seeing?
> 
> This heuristic is way too aggressive:
> 
> 	/*
> 	 * Try to keep 128MB max hysteris. If not possible,
> 	 * use half of RAM
> 	 */
> 	high_queued_sectors = (total_ram * 2) / 3;
> 	low_queued_sectors = high_queued_sectors - MB(128);
> 	if (low_queued_sectors < 0)
> 		low_queued_sectors = total_ram / 2;
> 
> 	/*
> 	 * for big RAM machines (>= 384MB), use more for I/O
> 	 */
> 	if (total_ram >= MB(384)) {
> 		high_queued_sectors = (total_ram * 4) / 5;
> 		low_queued_sectors = high_queued_sectors - MB(128);
> 	}
> 
> 2/3 of ram locked down in the I/O queue is way too much. 1/3 should be
> ok. big RAM machines needs way less than 1/3 locked down.

Yes I agree, that values should probably be tweaked a bit. I'll
try and squeeze some testing in to generate the best possible
values.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Andi Kleen]

On Fri, Jan 19, 2001 at 02:40:23AM +0100, Jens Axboe wrote:
> On Fri, Jan 19 2001, Andrea Arcangeli wrote:
> > On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
> > > Jens, can be the -blk patch the reason for the slowdown I'm seeing?
> > 
> > This heuristic is way too aggressive:
> > 
> > 	/*
> > 	 * Try to keep 128MB max hysteris. If not possible,
> > 	 * use half of RAM
> > 	 */
> > 	high_queued_sectors = (total_ram * 2) / 3;
> > 	low_queued_sectors = high_queued_sectors - MB(128);
> > 	if (low_queued_sectors < 0)
> > 		low_queued_sectors = total_ram / 2;
> > 
> > 	/*
> > 	 * for big RAM machines (>= 384MB), use more for I/O
> > 	 */
> > 	if (total_ram >= MB(384)) {
> > 		high_queued_sectors = (total_ram * 4) / 5;
> > 		low_queued_sectors = high_queued_sectors - MB(128);
> > 	}
> > 
> > 2/3 of ram locked down in the I/O queue is way too much. 1/3 should be
> > ok. big RAM machines needs way less than 1/3 locked down.
> 
> Yes I agree, that values should probably be tweaked a bit. I'll
> try and squeeze some testing in to generate the best possible
> values.

Please also add a sysctl. I always feel uncomfortable with such hardcoded
heuristics. There tends to be always another workload where the heuristic
fails and manual tuning is useful. 


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Fri, Jan 19 2001, Andi Kleen wrote:
> > Yes I agree, that values should probably be tweaked a bit. I'll
> > try and squeeze some testing in to generate the best possible
> > values.
> 
> Please also add a sysctl. I always feel uncomfortable with such hardcoded
> heuristics. There tends to be always another workload where the heuristic
> fails and manual tuning is useful. 

Sure, we can do that. But it should only really make a difference
for low memory machines, otherwise the numbers wouldn't change
so much. So the limits are not really that important, and only
need to be in the ball park.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Andi Kleen]

On Fri, Jan 19, 2001 at 02:47:45AM +0100, Jens Axboe wrote:
> On Fri, Jan 19 2001, Andi Kleen wrote:
> > > Yes I agree, that values should probably be tweaked a bit. I'll
> > > try and squeeze some testing in to generate the best possible
> > > values.
> > 
> > Please also add a sysctl. I always feel uncomfortable with such hardcoded
> > heuristics. There tends to be always another workload where the heuristic
> > fails and manual tuning is useful. 
> 
> Sure, we can do that. But it should only really make a difference
> for low memory machines, otherwise the numbers wouldn't change
> so much. So the limits are not really that important, and only
> need to be in the ball park.

Shouldn't it more depend on the bandwidth/latency of the IO device? 



-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Fri, Jan 19 2001, Andi Kleen wrote:
> Shouldn't it more depend on the bandwidth/latency of the IO device? 

Not really they should just make sure that we don't lock down
all buffers. The low water mark is just to make sure we don't
wake up readers/writers right after having blocked them.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Steven Cole]

On Thu, 18 Jan 2001, Marcelo Tosatti wrote:
> On my dbench runs I've noted a slowdown between pre4 and pre8 with 48
> threads. (128MB, 2 CPU's machine)

I ran dbench 48 four times in succession for 2.4.0 and 2.4.1-pre8.
The change in performance appears to be not significant.

This was performed with a Dell 420 dual P-III (733 MHz), with a ST317221A, 
ATA DISK drive and ReiserFS 3.6.25. 

Each test was done under the same conditions, running KDE 2.0, one xterm, 
right after booting.  

2.4.0:
Average    9.07868 MB/sec

Throughput 9.03546 MB/sec (NB=11.2943 MB/sec  90.3546 MBit/sec)
Throughput 8.99614 MB/sec (NB=11.2452 MB/sec  89.9614 MBit/sec)
Throughput 8.87756 MB/sec (NB=11.097 MB/sec  88.7756 MBit/sec)
Throughput 9.40556 MB/sec (NB=11.7569 MB/sec  94.0556 MBit/sec)

2.4.1-pre8:
Average    9.25707 MB/sec

Throughput 8.93444 MB/sec (NB=11.1681 MB/sec  89.3444 MBit/sec)
Throughput 9.43609 MB/sec (NB=11.7951 MB/sec  94.3609 MBit/sec)
Throughput 9.5075 MB/sec (NB=11.8844 MB/sec  95.075 MBit/sec)
Throughput 9.15026 MB/sec (NB=11.4378 MB/sec  91.5026 MBit/sec)

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Marcelo Tosatti]

On Thu, 18 Jan 2001, Steven Cole wrote:

> On Thu, 18 Jan 2001, Marcelo Tosatti wrote:
> > On my dbench runs I've noted a slowdown between pre4 and pre8 with 48
> > threads. (128MB, 2 CPU's machine)
> 
> I ran dbench 48 four times in succession for 2.4.0 and 2.4.1-pre8.
> The change in performance appears to be not significant.
> 
> This was performed with a Dell 420 dual P-III (733 MHz), with a ST317221A, 
> ATA DISK drive and ReiserFS 3.6.25. 
> 
> Each test was done under the same conditions, running KDE 2.0, one xterm, 
> right after booting.  
> 
> 2.4.0:
> Average    9.07868 MB/sec
> 
> Throughput 9.03546 MB/sec (NB=11.2943 MB/sec  90.3546 MBit/sec)
> Throughput 8.99614 MB/sec (NB=11.2452 MB/sec  89.9614 MBit/sec)
> Throughput 8.87756 MB/sec (NB=11.097 MB/sec  88.7756 MBit/sec)
> Throughput 9.40556 MB/sec (NB=11.7569 MB/sec  94.0556 MBit/sec)
> 
> 2.4.1-pre8:
> Average    9.25707 MB/sec
> 
> Throughput 8.93444 MB/sec (NB=11.1681 MB/sec  89.3444 MBit/sec)
> Throughput 9.43609 MB/sec (NB=11.7951 MB/sec  94.3609 MBit/sec)
> Throughput 9.5075 MB/sec (NB=11.8844 MB/sec  95.075 MBit/sec)
> Throughput 9.15026 MB/sec (NB=11.4378 MB/sec  91.5026 MBit/sec)

Steven,

The issue is the difference between pre4 and pre8.

Could you please try pre4 and report results ? 

Thanks


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Marcelo Tosatti]

Jens, 

Steven is a seeing a slowdown in his results, too. 


On Mon, 22 Jan 2001, Steven Cole wrote:

> On Thursday 18 January 2001 14:49, Marcelo Tosatti wrote:
> 
> > Steven,
> >
> > The issue is the difference between pre4 and pre8.
> >
> > Could you please try pre4 and report results ?
> >
> > Thanks
> 
> Ok, here are the results for 2.4.1-pre4, along with the original -pre8 
> results.  There does appear to be a slowdown.
> 
> 2.4.1-pre4
> average:   9.77876 MB/sec
> 
> Throughput 10.3677 MB/sec (NB=12.9597 MB/sec  103.677 MBit/sec)
> Throughput 9.61291 MB/sec (NB=12.0161 MB/sec  96.1291 MBit/sec)
> Throughput 9.92944 MB/sec (NB=12.4118 MB/sec  99.2944 MBit/sec)
> Throughput 9.20502 MB/sec (NB=11.5063 MB/sec  92.0502 MBit/sec)
> 
> 2.4.1-pre8:
> Average    9.25707 MB/sec
> 
> Throughput 8.93444 MB/sec (NB=11.1681 MB/sec  89.3444 MBit/sec)
> Throughput 9.43609 MB/sec (NB=11.7951 MB/sec  94.3609 MBit/sec)
> Throughput 9.5075 MB/sec (NB=11.8844 MB/sec  95.075 MBit/sec)
> Throughput 9.15026 MB/sec (NB=11.4378 MB/sec  91.5026 MBit/sec)
> 
> This was done on a dual P-III, 256MB machine.
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Mon, Jan 22 2001, Marcelo Tosatti wrote:
> 
> Jens, 
> 
> Steven is a seeing a slowdown in his results, too. 
> 
> 
> On Mon, 22 Jan 2001, Steven Cole wrote:
> 
> > On Thursday 18 January 2001 14:49, Marcelo Tosatti wrote:
> > 
> > > Steven,
> > >
> > > The issue is the difference between pre4 and pre8.
> > >
> > > Could you please try pre4 and report results ?
> > >
> > > Thanks
> > 
> > Ok, here are the results for 2.4.1-pre4, along with the original -pre8 
> > results.  There does appear to be a slowdown.
> > 
> > 2.4.1-pre4
> > average:   9.77876 MB/sec
> > 
> > Throughput 10.3677 MB/sec (NB=12.9597 MB/sec  103.677 MBit/sec)
> > Throughput 9.61291 MB/sec (NB=12.0161 MB/sec  96.1291 MBit/sec)
> > Throughput 9.92944 MB/sec (NB=12.4118 MB/sec  99.2944 MBit/sec)
> > Throughput 9.20502 MB/sec (NB=11.5063 MB/sec  92.0502 MBit/sec)
> > 
> > 2.4.1-pre8:
> > Average    9.25707 MB/sec
> > 
> > Throughput 8.93444 MB/sec (NB=11.1681 MB/sec  89.3444 MBit/sec)
> > Throughput 9.43609 MB/sec (NB=11.7951 MB/sec  94.3609 MBit/sec)
> > Throughput 9.5075 MB/sec (NB=11.8844 MB/sec  95.075 MBit/sec)
> > Throughput 9.15026 MB/sec (NB=11.4378 MB/sec  91.5026 MBit/sec)
> > 
> > This was done on a dual P-III, 256MB machine.

Stephen,

To rule out other factors, could you try 2.4.1-pre8 with
blk_started_io() and blk_finished_io() defined to nothing
in include/linux/blkdev.h? This will disable the max-locked-buffers
heuristic.

Also, are the numbers above consistent for repeated runs (with
boots in between)?

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Steven Cole]

On Monday 22 January 2001 16:11, Jens Axboe wrote:
>
> Stephen,
>
> To rule out other factors, could you try 2.4.1-pre8 with
> blk_started_io() and blk_finished_io() defined to nothing
> in include/linux/blkdev.h? This will disable the max-locked-buffers
> heuristic.
>
> Also, are the numbers above consistent for repeated runs (with
> boots in between)?

In the following table, 2.4.1-pre8x refers to -pre8 with
linux/include/linux/blkdev.h modified as suggested.
A diff to show the changes made is included at the end.

Here is a summary of the data, followed by the data
for the individual runs.  Each of the four runs were performed
in rapid succession, with no boots in between. 

Each run set had at least one boot in between.
This machine is dual 733mhz p-III, 255MB.

I didn't copy to lkml because this is rather lengthy,
but feel free to copy whatever you think is of general
interest.

Steven

2.4.1-pre4  run set 1 average:   9.77876 MB/sec
2.4.1-pre4  run set 2 average:   9.78904 MB/sec

2.4.1-pre8x run set 1 average:   9.56098 MB/sec
2.4.1-pre8x run set 2 average:   9.54694 MB/sec

2.4.1-pre8  run set 1 average:   9.25707 MB/sec
2.4.1-pre8  run set 2 average:   9.64841 MB/sec


2.4.1-pre4  (performed 18-January-2001)
average:   9.77876 MB/sec

Throughput 10.3677 MB/sec (NB=12.9597 MB/sec  103.677 MBit/sec)
Throughput 9.61291 MB/sec (NB=12.0161 MB/sec  96.1291 MBit/sec)
Throughput 9.92944 MB/sec (NB=12.4118 MB/sec  99.2944 MBit/sec)
Throughput 9.20502 MB/sec (NB=11.5063 MB/sec  92.0502 MBit/sec)

2.4.1-pre4  (performed 23-January-2001, repeat of above)
average:   9.78904 MB/sec

Throughput 10.1134 MB/sec (NB=12.6417 MB/sec  101.134 MBit/sec)
Throughput 9.71752 MB/sec (NB=12.1469 MB/sec  97.1752 MBit/sec)
Throughput 9.71035 MB/sec (NB=12.1379 MB/sec  97.1035 MBit/sec)
Throughput 9.6149 MB/sec (NB=12.0186 MB/sec  96.149 MBit/sec)

2.4.1-pre8x (performed 23-January-2001)
average:   9.56098 MB/sec

Throughput 9.98585 MB/sec (NB=12.4823 MB/sec  99.8585 MBit/sec)
Throughput 9.51678 MB/sec (NB=11.896 MB/sec  95.1678 MBit/sec)
Throughput 9.45918 MB/sec (NB=11.824 MB/sec  94.5918 MBit/sec)
Throughput 9.28211 MB/sec (NB=11.6026 MB/sec  92.8211 MBit/sec)

2.4.1-pre8x (performed 23-January-2001, repeat of above)
average:   9.54694 MB/sec

Throughput 9.59079 MB/sec (NB=11.9885 MB/sec  95.9079 MBit/sec)
Throughput 9.35774 MB/sec (NB=11.6972 MB/sec  93.5774 MBit/sec)
Throughput 9.60368 MB/sec (NB=12.0046 MB/sec  96.0368 MBit/sec)
Throughput 9.63557 MB/sec (NB=12.0445 MB/sec  96.3557 MBit/sec)

2.4.1-pre8: (performed 18-January-2001)
Average    9.25707 MB/sec

Throughput 8.93444 MB/sec (NB=11.1681 MB/sec  89.3444 MBit/sec)
Throughput 9.43609 MB/sec (NB=11.7951 MB/sec  94.3609 MBit/sec)
Throughput 9.5075 MB/sec (NB=11.8844 MB/sec  95.075 MBit/sec)
Throughput 9.15026 MB/sec (NB=11.4378 MB/sec  91.5026 MBit/sec)

2.4.1-pre8  (performed 23-January-2001, repeat of above)
average:   9.64841 MB/sec

Throughput 9.75834 MB/sec (NB=12.1979 MB/sec  97.5834 MBit/sec)
Throughput 9.70084 MB/sec (NB=12.1261 MB/sec  97.0084 MBit/sec)
Throughput 9.34317 MB/sec (NB=11.679 MB/sec  93.4317 MBit/sec)
Throughput 9.79128 MB/sec (NB=12.2391 MB/sec  97.9128 MBit/sec)

Here is the modification made to blkdev.h:

--- blkdev.h.orig       Tue Jan 23 09:07:43 2001
+++ blkdev.h    Tue Jan 23 09:08:32 2001
@@ -207,13 +207,7 @@
 }
 
 #define blk_finished_io(nsects)                                \
-       atomic_sub(nsects, &queued_sectors);            \
-       if (atomic_read(&queued_sectors) < 0) {         \
-               printk("block: queued_sectors < 0\n");  \
-               atomic_set(&queued_sectors, 0);         \
-       }
 
 #define blk_started_io(nsects)                         \
-       atomic_add(nsects, &queued_sectors);
 
 #endif

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Tue, Jan 23 2001, Steven Cole wrote:
> In the following table, 2.4.1-pre8x refers to -pre8 with
> linux/include/linux/blkdev.h modified as suggested.
> A diff to show the changes made is included at the end.
> 
> Here is a summary of the data, followed by the data
> for the individual runs.  Each of the four runs were performed
> in rapid succession, with no boots in between. 

Thanks! Could I talk you into doing one last run? pre8 with
include/linux/elevator.h having these values set for
ELEVATOR_LINUS:

#define ELEVATOR_LINUS                                                  \
((elevator_t) {                                                         \
	1000000,		/* read passovers */
	2000000,		/* write passovers */

Just do this mod on top of your x tree.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Steven Cole]

On Tuesday 23 January 2001 13:54, Jens Axboe wrote:
>
> Thanks! Could I talk you into doing one last run? pre8 with
> include/linux/elevator.h having these values set for
> ELEVATOR_LINUS:
>
Here are two sets of dbench 48 runs with that mod. I can't explain why the
second set is faster.  The second set was performed with no reboot after the 
first set.  The individual runs were performed with no wait in-between.

Steven

2.4.1-pre8 with changes to elevator.h, first run set
average:   9.52569 MB/sec

Throughput 9.51356 MB/sec (NB=11.892 MB/sec  95.1356 MBit/sec)
Throughput 9.43096 MB/sec (NB=11.7887 MB/sec  94.3096 MBit/sec)
Throughput 9.54195 MB/sec (NB=11.9274 MB/sec  95.4195 MBit/sec)
Throughput 9.61631 MB/sec (NB=12.0204 MB/sec  96.1631 MBit/sec)

2.4.1-pre8 same as above, second run set
average:   10.1621 MB/sec

Throughput 10.1236 MB/sec (NB=12.6546 MB/sec  101.236 MBit/sec)
Throughput 10.0304 MB/sec (NB=12.5381 MB/sec  100.304 MBit/sec)
Throughput 10.1844 MB/sec (NB=12.7305 MB/sec  101.844 MBit/sec)
Throughput 10.3099 MB/sec (NB=12.8873 MB/sec  103.099 MBit/sec)

Here is the change I made to elevator.h which you suggested:

--- elevator.h.orig     Wed Jan 24 07:12:00 2001
+++ elevator.h  Wed Jan 24 07:12:47 2001
@@ -94,8 +94,8 @@
 
 #define ELEVATOR_LINUS                                                 \
 ((elevator_t) {                                                              
  \
-       8192,                           /* read passovers */            \
-       16384,                          /* write passovers */           \
+       1000000,                                /* read passovers */          
  \
+       2000000,                                /* write passovers */         
  \
                                                                        \
        elevator_linus_merge,           /* elevator_merge_fn */         \
        elevator_linus_merge_cleanup,   /* elevator_merge_cleanup_fn */ \

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe]

On Wed, Jan 24 2001, Steven Cole wrote:
> > Thanks! Could I talk you into doing one last run? pre8 with
> > include/linux/elevator.h having these values set for
> > ELEVATOR_LINUS:
> >
> Here are two sets of dbench 48 runs with that mod. I can't explain why the
> second set is faster.  The second set was performed with no reboot after the 
> first set.  The individual runs were performed with no wait in-between.

Was this the 2.4.1-pre8x tree? Regardless, it's about back to the
same dbench performance that we saw earlier with the more unfair
setup. The blk-xx changes in recent 2.4.1-pre were not meant (and
never claimed :-) to boost dbench performance. That's actually
quite easy to do: let one thread completely finish I/O, _then_
move on to the next one. This isn't what we want in Real Life.

The fact that dbench performance remains pretty good from stock
kernel against the changes I told you to do is excellent and
mainly due to the batch freeing changes.

In most real life situations, throughput on account of no care for
latency is not ideal. Even though dbench performance drops a bit,
you will see better distribution of the bandwidth between the
threads. Think file serving.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1pre8 slowdown on dbench tests

[Steven Cole]

On Wednesday 24 January 2001 09:44, Jens Axboe wrote:
> On Wed, Jan 24 2001, Steven Cole wrote:
> > > Thanks! Could I talk you into doing one last run? pre8 with
> > > include/linux/elevator.h having these values set for
> > > ELEVATOR_LINUS:
> >
> > Here are two sets of dbench 48 runs with that mod. I can't explain why
> > the second set is faster.  The second set was performed with no reboot
> > after the first set.  The individual runs were performed with no wait
> > in-between.
>
> Was this the 2.4.1-pre8x tree? Regardless, it's about back to the

Yes, that kernel included the other change which was to blkdev.h which 
you suggested.  I ran dbench 48 four more times right after the previous 
email.  Here are those results, using exactly the same kernel (2.4.1-pre8 
with changes to blkdev.h and elevator.h).

Throughput 9.52243 MB/sec (NB=11.903 MB/sec  95.2243 MBit/sec)
Throughput 9.98258 MB/sec (NB=12.4782 MB/sec  99.8258 MBit/sec)
Throughput 9.41459 MB/sec (NB=11.7682 MB/sec  94.1459 MBit/sec)
Throughput 9.23102 MB/sec (NB=11.5388 MB/sec  92.3102 MBit/sec)

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/