choice of raid5 checksumming algorithm wrong ?

DISCUSSION Soeren Sonnenburg 4 participants 7 messages Jan 11, 2003 – Jan 12, 2003

Share & tools

Soeren Sonnenburg

author

2003-01-11 06:21 UTC #0 lore raw

Hi!

I really do wonder whether the displayed message is wrong or why it always chooses the slowest checksumming function (happens with 2.4.19 - 21pre3)

2.4.20:

Jan  7 18:32:22 sun kernel: raid5: measuring checksumming speed
Jan  7 18:32:22 sun kernel: 8regs     :  3054.400 MB/sec
Jan  7 18:32:22 sun kernel: 32regs    :  2696.800 MB/sec
Jan  7 18:32:22 sun kernel: pIII_sse  :  1614.000 MB/sec
Jan  7 18:32:22 sun kernel: pII_mmx   :  4672.000 MB/sec
Jan  7 18:32:22 sun kernel: p5_mmx    :  5984.000 MB/sec
Jan  7 18:32:22 sun kernel: raid5: using function: pIII_sse (1614.000 MB/sec)

21pre2:

Jan  5 19:18:47 sun kernel: raid5: measuring checksumming speed
Jan  5 19:18:47 sun kernel: 8regs     :  3054.000 MB/sec
Jan  5 19:18:47 sun kernel: 32regs    :  2697.200 MB/sec
Jan  5 19:18:47 sun kernel: pIII_sse  :  2574.000 MB/sec
Jan  5 19:18:47 sun kernel: pII_mmx   :  4671.600 MB/sec
Jan  5 19:18:47 sun kernel: p5_mmx    :  5984.000 MB/sec
Jan  5 19:18:47 sun kernel: raid5: using function: pIII_sse (2574.000 MB/sec)
Jan  5 19:18:47 sun kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27

21pre3:

Jan  7 21:38:12 sun kernel: raid5: measuring checksumming speed
Jan  7 21:38:12 sun kernel: 8regs     :  3055.200 MB/sec
Jan  7 21:38:12 sun kernel: 32regs    :  2697.200 MB/sec
Jan  7 21:38:12 sun kernel: pIII_sse  :  5658.400 MB/sec
Jan  7 21:38:12 sun kernel: pII_mmx   :  4672.400 MB/sec
Jan  7 21:38:12 sun kernel: p5_mmx    :  5984.800 MB/sec
Jan  7 21:38:12 sun kernel: raid5: using function: pIII_sse (5658.400 MB/sec)

it is always the same system...athlon xp2.4+...
Soeren.

Lionel Bouton

2003-01-11 15:36 UTC #1 lore raw

Quoted 7 lines · Soeren Sonnenburg

Hi!
I really do wonder whether the displayed message is wrong or why it always chooses the slowest checksumming function (happens with 2.4.19 - 21pre3)

SSE is always preferred because unlike other checksumming code it doesn't use the processor caches when reading/writing data/checksum. This is slower (if several GB/s can be considered slow) for the checksumming but far better for the overall system performance.

LB.

Rene Rebe

2003-01-11 19:33 UTC #2 lore raw

Hi.

I also consider the kprint message a useability bug - and this is why I posted a patch that prints out that the algorithm is choosen to write "arround" the L2 cache ... - We patch this in our ROCK Linux standard patches ...

On: Sat, 11 Jan 2003 16:45:04 +0100,

Quoted 9 lines · Lionel Bouton

Quoted 7 lines · Soeren Sonnenburg
Hi!
I really do wonder whether the displayed message is wrong or why it always chooses the slowest checksumming function (happens with 2.4.19 - 21pre3)

Quoted 6 lines

SSE is always preferred because unlike other checksumming code it doesn't use the processor caches when reading/writing data/checksum. This is slower (if several GB/s can be considered slow) for the checksumming but far better for the overall system performance.
LB.

- René

Signature · 7 lines

René Rebe - Europe/Germany/Berlin
e-mail:   [email protected], [email protected]
web:      www.rocklinux.org, drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Soeren Sonnenburg

author

2003-01-11 19:51 UTC #3 lore raw

Quoted 6 lines · Rene Rebe

Hi.
I also consider the kprint message a useability bug - and this is why I posted a patch that prints out that the algorithm is choosen to write "arround" the L2 cache ... - We patch this in our ROCK Linux standard patches ...

I would vote for such a cosmetic patch to be included...

Soeren.

Quoted 28 lines

On: Sat, 11 Jan 2003 16:45:04 +0100,
Quoted 9 lines · Lionel Bouton
Quoted 7 lines · Soeren Sonnenburg
Hi!
I really do wonder whether the displayed message is wrong or why it always chooses the slowest checksumming function (happens with 2.4.19 - 21pre3)
Quoted 6 lines
SSE is always preferred because unlike other checksumming code it doesn't use the processor caches when reading/writing data/checksum. This is slower (if several GB/s can be considered slow) for the checksumming but far better for the overall system performance.
LB.
- René
Signature · 7 lines
René Rebe - Europe/Germany/Berlin
e-mail:   [email protected], [email protected]
web:      www.rocklinux.org, drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Rene Rebe

2003-01-11 20:15 UTC #4 lore raw

Hi.

In the case s.o. wants to pull the patch:

http://www.rocklinux.org/sources/package/base/linux24/82-raid5-niceer-output.patch

It is only a one-liner. It is not really nice since I print the "writing arround L2 cache" text when XOR_SELECT_TEMPLATE is defined - this might also be the case for an later AlitVec version for PowerPC or so. So we might want a more generic text - or a text in the appropriated .h file whetre XOR_SELECT_TEMPLATE is defined ...

On: 11 Jan 2003 20:52:00 +0100,

Quoted 48 lines · Soeren Sonnenburg

Quoted 6 lines · Rene Rebe
Hi.
I also consider the kprint message a useability bug - and this is why I posted a patch that prints out that the algorithm is choosen to write "arround" the L2 cache ... - We patch this in our ROCK Linux standard patches ...
I would vote for such a cosmetic patch to be included...
Soeren.
Quoted 11 lines
On: Sat, 11 Jan 2003 16:45:04 +0100,
Quoted 9 lines · Lionel Bouton
Quoted 7 lines · Soeren Sonnenburg
Hi!
I really do wonder whether the displayed message is wrong or why it always chooses the slowest checksumming function (happens with 2.4.19 - 21pre3)
Quoted 17 lines
Quoted 6 lines
SSE is always preferred because unlike other checksumming code it doesn't use the processor caches when reading/writing data/checksum. This is slower (if several GB/s can be considered slow) for the checksumming but far better for the overall system performance.
LB.
- René
Signature · 7 lines
René Rebe - Europe/Germany/Berlin
e-mail:   [email protected], [email protected]
web:      www.rocklinux.org, drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Mr. James W. Laferriere

2003-01-12 14:40 UTC #5 lore raw

Hello Rene , All , How about just printing the algorithm that is chosen & not the others ? Just an idea . JimL

Quoted 8 lines · Rene Rebe

Hi.
In the case s.o. wants to pull the patch:
http://www.rocklinux.org/sources/package/base/linux24/82-raid5-niceer-output.patch
It is only a one-liner. It is not really nice since I print the "writing arround L2 cache" text when XOR_SELECT_TEMPLATE is defined - this might also be the case for an later AlitVec version for PowerPC or so. So we might want a more generic text - or a text in the appropriated .h file whetre XOR_SELECT_TEMPLATE is defined ...

Signature · 5 lines

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | [email protected] | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Rene Rebe

2003-01-12 16:08 UTC #6 lore raw

Hi.

Hm - for me the different throughputs are a nice initial benchmark ... - I like them being printed out.

On: Sun, 12 Jan 2003 09:44:44 -0500 (EST),

Quoted 25 lines · Mr. James W. Laferriere

Hello Rene , All , How about just printing the algorithm that is chosen & not the others ? Just an idea . JimL
Quoted 8 lines · Rene Rebe
Hi.
In the case s.o. wants to pull the patch:
http://www.rocklinux.org/sources/package/base/linux24/82-raid5-niceer-output.patch
It is only a one-liner. It is not really nice since I print the "writing arround L2 cache" text when XOR_SELECT_TEMPLATE is defined - this might also be the case for an later AlitVec version for PowerPC or so. So we might want a more generic text - or a text in the appropriated .h file whetre XOR_SELECT_TEMPLATE is defined ...
Signature · 10 lines
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | [email protected] | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/