Hi there,
I am CC:ing this to Andrea Arcangeli because he is credited at the top of
drivers/block/ll_rw_blk.c as writing the elevator code.
On Sun, 13 Aug 2000, Jens Axboe wrote:
> On Sun, Aug 13 2000, Corin Hartland-Swann wrote:
> > The fact remains that disk performance is much worse under 2.2.16 and
> > heavy loads than under 2.2.15 - what I was trying to find out was what
>
> A new elevator was introduced into 2.2.16, that may be affecting
> results. Try using elvtune from util-linux to set read_latency,
> write_latency, and max_bomb_segments much higher and see if that brings
> it back to 2.2.15 levels. (hint: use something big, like 10000000
> for read/write latency, and 128 for max_bomb_segments).
I have tried this out, and found that the default settings were:
elevator ID=232 read_latency=128 write_latency=8192 max_bomb_segments=4
Can anyone point me to any documentation on this elevator code? I was
wondering what exactly the different variables do...
I found that increasing the read_latency to match write_latency fixes the
problems perfectly - thanks for the pointer!
As a recap, here are the 2.2.15 (last known good) results:
==> 2.2.15 <==
----- ------ ------- ---- ------------- -------------- --------------
Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
----- ------ ------- ---- ------------- -------------- --------------
/mnt/ 256 4096 1 27.1371 10.3% 26.7979 23.0% 146.187 0.95%
/mnt/ 256 4096 2 27.1219 10.7% 26.6606 23.2% 142.233 0.60%
/mnt/ 256 4096 4 26.9915 10.6% 26.4289 22.9% 142.789 0.50%
/mnt/ 256 4096 16 26.4320 10.5% 26.1310 23.0% 147.424 0.52%
/mnt/ 256 4096 32 25.3407 10.1% 25.6822 22.7% 150.750 0.57%
And here's the default elevator settings:
==> 2.2.16 read_latency=128 write_latency=8192 max_bombs=4 <==
----- ------ ------- ---- ------------- -------------- --------------
Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
----- ------ ------- ---- ------------- -------------- --------------
/mnt/ 256 8192 1 26.8839 10.2% 25.6472 22.4% 141.201 1.07%
/mnt/ 256 8192 2 20.4838 8.40% 25.6120 22.8% 136.777 0.80%
/mnt/ 256 8192 4 13.1292 6.09% 25.5942 23.0% 137.310 0.72%
/mnt/ 256 8192 8 10.5354 5.56% 25.4997 23.3% 139.946 0.74%
/mnt/ 256 8192 16 8.48961 5.23% 25.4394 23.4% 142.674 0.81%
/mnt/ 256 8192 32 6.97233 5.51% 25.2732 23.3% 144.932 0.91%
Increasing read_latency to match write_latency fixes the problem:
==> 2.2.16 read_latency=8192 write_latency=8192 max_bombs=4 <==
----- ------ ------- ---- ------------- -------------- --------------
Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
----- ------ ------- ---- ------------- -------------- --------------
/mnt/ 256 4096 1 27.2405 11.3% 26.2348 23.1% 147.336 0.86%
/mnt/ 256 4096 2 27.1620 11.2% 26.1579 23.4% 142.416 0.54%
/mnt/ 256 4096 4 27.0072 11.4% 25.8826 23.3% 143.016 0.48%
/mnt/ 256 4096 8 26.7318 11.5% 25.5838 23.2% 145.882 0.44%
/mnt/ 256 4096 16 26.2688 11.3% 25.5004 23.4% 149.257 0.50%
/mnt/ 256 4096 32 25.1737 11.1% 25.2690 23.3% 151.729 0.54%
Increasing the read_latency and write_latency to 10,000,000 results in
similar throughput, but catastrophic seek performance:
==> 2.2.16 read_latency=10M write_latency=10M max_bombs=128 <==
----- ------ ------- ---- ------------- -------------- --------------
Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
----- ------ ------- ---- ------------- -------------- --------------
/mnt/ 256 4096 1 26.9227 11.6% 26.5720 23.4% 6.02902 4.12%
/mnt/ 256 4096 2 26.7714 11.5% 26.3389 23.3% 0.00012 6.24%
/mnt/ 256 4096 4 26.7642 11.4% 26.0954 23.1% 0.00018 7.83%
/mnt/ 256 4096 8 26.4734 11.3% 25.7610 23.0% 0.00024 9.70%
/mnt/ 256 4096 16 26.0630 11.4% 25.6312 23.2% 0.00030 1.16%
/mnt/ 256 4096 32 25.1940 11.1% 25.4283 23.1% 0.00036 1.39%
I used the elvtune from
ftp://ftp.win.tue.nl/pub/home/mirror/linux/utils/util-linux/util-linux-2.10o.tar.bz2
Now, does anyone (Andrea in particular) know where the defaults are set? I
assume that setting read_latency to much lower than write_latency was an
accident, but can't find whereabouts these values are allocated in the
kernel. If this could be modified in the kernel then this would get disk
performance back up to scratch...
As an aside (sorry, I keep going off on tangents), can anybody explain why
writes are twice as expensive in CPU-time as reads? This is not a new
problem, just an observation I've made looking at all of these results...
Thanks,
Corin
/------------------------+-------------------------------------\
| Corin Hartland-Swann | Direct: +44 (0) 20 7544 4676 |
| Commerce Internet Ltd | Mobile: +44 (0) 79 5854 0027 |
| 22 Cavendish Buildings | Tel: +44 (0) 20 7491 2000 |
| Gilbert Street | Fax: +44 (0) 20 7491 2010 |
| Mayfair | Web: http://www.commerce.uk.net/ |
| London W1K 5HJ | E-Mail: cdhs@commerce.uk.net |
\------------------------+-------------------------------------/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:33 EST