as Linus and Andrea suggested, I tried pre-2.3.8-2 and 2.3.7-andrea1
patches. Here are the results.
2.3.8-pre2: no oops on swapon, bonnie on /dev/hdb and /dev/hdc run fine.
/dev/hdc w/ BM DMA:
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
%CPU
100 1641 96.1 6861 12.4 2934 6.8 1359 80.8 6033 9.0 129.5
1.8
/deb/hdb w/ BM DMA:
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
%CPU
100 1677 98.2 6077 10.8 2883 6.3 1388 81.9 6069 9.0 124.5
2.3
Then I tried to test /dev/sda (/var, QUANTUM LPS540S on a
Diamond Fireport 40, sym53c8xx driver) but I got an oops:
**************************************************************************
...
08:03: rw=0, want=2138996093, limit=292864
attempt to access beyond end of device
08:03: rw=0, want=2138996093, limit=292864
attempt to access beyond end of device
08:03: rw=0, want=0, limit=292864
attempt to access beyond end of device
08:03: rw=0, want=0, limit=292864
kernel BUG at buffer.c:1235!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c01292cc>]
EFLAGS: 00010292
eax: 0000001d ebx: 00000000 ecx: c01c9428 edx: c3e4e000
esi: c02ce470 edi: c2398ec0 ebp: c2ba9e74 esp: c2ba9e2c
ds: 0018 es: 0018 ss: 0018
Process bonnie (pid: 783, process nr: 42, stackpage=c2ba9000)
Stack: 000004d3 c01d07a0 c2398ec0 00000000 c016b5c1 c2398ec0 00000000
00000001
c2ba9ed4 00000004 00000002 00000286 00000003 00000020 000000ff
c0128bcd
ffffffff fffffffe 00000003 c016b6fd 00000008 00000000 c2398ec0
c2398f20
Call Trace: [<c016b5c1>] [<c0128bcd>] [<c016b6fd>] [<c0129ff9>]
[<c0129ff9>] [<c
011e049>] [<c011e061>]
[<c011ef5f>] [<c011f205>] [<c011f150>] [<c0127005>] [<c0109e38>]
[<c01000
2b>]
Code: 0f 0b 83 c4 0c c7 46 34 00 00 00 00 0f b3 5e 18 19 c0 85 c0
Warning: trailing garbage ignored on Code: line
Text: 'Code: 0f 0b 83 c4 0c c7 46 34 00 00 00 00 0f b3 5e 18 19 c0 85
c0 '
Garbage: ' '
>>EIP: c01292cc <end_buffer_io_async+e4/130>
Trace: c016b5c1 <make_request+475/480>
Trace: c0128bcd <__brelse+55/68>
Trace: c016b6fd <ll_rw_block+131/190>
Trace: c0129ff9 <block_read_full_page+189/1e0>
Trace: c0129ff9 <block_read_full_page+189/1e0>
Trace: c011e049 <try_to_read_ahead+81/b0>
Trace: c011e061 <try_to_read_ahead+99/b0>
Trace: c011ef5f <do_generic_file_read+623/814>
Code: c01292cc <end_buffer_io_async+e4/130> 00000000 <_EIP>: <===
Code: c01292cc <end_buffer_io_async+e4/130> 0: 0f
0b
ud2a <===
Code: c01292ce <end_buffer_io_async+e6/130> 2: 83 c4
0c
addl $0xc,%esp
Code: c01292d1 <end_buffer_io_async+e9/130> 5: c7 46 34 00 00
00 00
movl $0x0,0x34(%esi)
Code: c01292d8 <end_buffer_io_async+f0/130> c: 0f b3 5e
18
btrl %ebx,0x18(%esi)
Code: c01292dc <end_buffer_io_async+f4/130> 10: 19
c0
sbbl %eax,%eax
Code: c01292de <end_buffer_io_async+f6/130> 12: 85
c0
testl %eax,%eax
**************************************************************************
Then I rebooted with 2.3.7-andrea1. Here are the results.
/dev/hdc w/ BM DMA:
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
%CPU
100 1700 99.5 6832 13.0 2808 5.9 1352 82.7 6143 9.2 129.4
1.8
/dev/hdb w/ BM DMA:
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
%CPU
100 1703 99.6 7217 13.6 2844 6.3 1381 82.3 6165 8.9 121.2
1.3
Again, I wanted to test my SCSI disk:
**************************************************************************
...
attempt to access beyond end of device
08:03: rw=0, want=2138996093, limit=292864
attempt to access beyond end of device
08:03: rw=0, want=2138996093, limit=292864
attempt to access beyond end of device
08:03: rw=0, want=0, limit=292864
attempt to access beyond end of device
08:03: rw=0, want=0, limit=292864
kernel BUG at buffer.c:1272!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0129ccc>]
EFLAGS: 00010292
eax: 0000001d ebx: c0349adc ecx: c01c9b68 edx: c3b24000
esi: 00000000 edi: c0bc1c20 ebp: c3d89e6c esp: c3d89ddc
ds: 0018 es: 0018 ss: 0018
Process bonnie (pid: 780, process nr: 7, stackpage=c3d89000)
Stack: 000004f8 c01d0cc0 00000003 00000000 c016c3e6 c0bc1c20 00000000
00000001
00000003 c3d89ed0 c01e7e00 c0bc1e00 00000246 0003edc2 ffff0000
c2081b60
c12be2a0 c3d89e54 c3d89e54 00000020 01234567 c3d88000 00000002
fffffffe
Call Trace: [<c016c3e6>] [<c012939f>] [<c012962c>] [<c016c524>]
[<c012ab29>] [<c
011e58a>] [<c011e5a2>]
[<c011f2e0>] [<c019bd2b>] [<c011f5f5>] [<c011f548>] [<c0127915>]
[<c0109e
a8>] [<c010002b>]
Code: 0f 0b 83 c4 0c c7 43 40 00 00 00 00 0f b3 73 18 19 c0 85 c0
Warning: trailing garbage ignored on Code: line
Text: 'Code: 0f 0b 83 c4 0c c7 43 40 00 00 00 00 0f b3 73 18 19 c0 85
c0 '
Garbage: ' '
>>EIP: c0129ccc <end_buffer_io_async+bc/108>
Trace: c016c3e6 <make_request+7fa/808>
Trace: c012939f <getblk+23/108>
Trace: c012962c <__brelse+28/3c>
Trace: c016c524 <ll_rw_block+130/1bc>
Trace: c012ab29 <block_read_full_page+1d9/230>
Trace: c011e58a <try_to_read_ahead+82/b0>
Trace: c011e5a2 <try_to_read_ahead+9a/b0>
Trace: c011f2e0 <do_generic_file_read+644/8ac>
Code: c0129ccc <end_buffer_io_async+bc/108> 00000000 <_EIP>: <===
Code: c0129ccc <end_buffer_io_async+bc/108> 0: 0f
0b
ud2a <===
Code: c0129cce <end_buffer_io_async+be/108> 2: 83 c4
0c
addl $0xc,%esp
Code: c0129cd1 <end_buffer_io_async+c1/108> 5: c7 43 40 00 00
00 00
movl $0x0,0x40(%ebx)
Code: c0129cd8 <end_buffer_io_async+c8/108> c: 0f b3 73
18
btrl %esi,0x18(%ebx)
Code: c0129cdc <end_buffer_io_async+cc/108> 10: 19
c0
sbbl %eax,%eax
Code: c0129cde <end_buffer_io_async+ce/108> 12: 85
c0
testl %eax,%eax
**************************************************************************
So something is still wrong with my SCSI disk under 2.3.7+.
To show what performance can I expect from this thing, I give the
bonnie test results for my /dev/sda with 2.2.10:
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
%CPU
100 1273 76.3 1847 5.3 810 4.7 1307 78.4 1804 3.5 74.6
1.4
To sum the results, I made a little comparison chart for my disks,
only with the DMA block operations and kernel compile times.
/dev/hdb
Kernel Block write Block read Kernel compile time
K/sec %CPU K/sec %CPU dep bzImage
2.2.10 7958 16.8 5891 8.7 1:06.89 8:45.87
2.3.7 6006 11.6 5946 8.6 1:09.02 8:46.99
2.3.8-pre2 6077 10.8 6069 9.0 1:10.11 8:57.25
2.3.7-andrea1 7217 13.6 6165 8.9 0:49.38 8:42.29
/dev/hdc
Kernel Block write Block read Kernel compile time
K/sec %CPU K/sec %CPU dep bzImage
2.2.10 7677 15.7 6132 9.2 1:09.39 8:47.29
2.3.7 5925 10.9 6089 10.1 1:05.51 8:55.25
2.3.8-pre2 6861 12.4 6033 9.0 1:07.99 8:54.81
2.3.7-andrea1 6832 13.0 6143 9.2 1:02.61 8:54.73
In the getc/putc tests mainly the processor does the work, so they
do not differ too much, but as I mentioned in my first post 2.3.7+
does it with less CPU power than 2.2.10.
The block read operations show almost the same result, 4.6% difference
between the slowest and the fastest on /dev/hdb, 1.8% on /dev/hdc.
The interesting part is the block write. 2.3.8-pre2 performs the same
as 2.3.7 and 2.3.7-andrea1 is a lot faster on /dev/hdb. 2.3.8-pre2
performs the same as 2.3.7-andrea1 on /dev/hdc. Why is that? I would
expect the same differences/rates in the above combinations.
I have these:
/dev/hda: QUANTUM FIREBALL1280A
/dev/hdb: QUANTUM FIREBALL_TM2110A
/dev/hdc: QUANTUM FIREBALL_TM1700A
/dev/hdd: TOSHIBA CD-ROM XM-6002B
The three disks can do multi-word dma mode 2, the CDROM can do
multi-word dma mode 1. With 2.2.10 I have to use hdparm to set hdc
and hdd to dma mode, with 2.3.x this is automatic. I just wanted
to say BIG THANKS to the one who did the new IDE scheme. :)
Regards,
Zoltan Boszormenyi
-
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/