choice of raid5 checksumming algorithm wrong ?

choice of raid5 checksumming algorithm wrong ?

[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)

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.

Re: choice of raid5 checksumming algorithm wrong ?

[Lionel Bouton]

Soeren Sonnenburg wrote:

>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.

Re: choice of raid5 checksumming algorithm wrong ?

[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 ...

On: Sat, 11 Jan 2003 16:45:04 +0100,
    Lionel Bouton <Lionel.Bouton@inet6.fr> wrote:
> Soeren Sonnenburg wrote:
> 
> >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.

- René

--  
René Rebe - Europe/Germany/Berlin
e-mail:   rene.rebe@gmx.net, rene@rocklinux.org
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.

Re: choice of raid5 checksumming algorithm wrong ?

[Soeren Sonnenburg]

On Sat, 2003-01-11 at 20:39, Rene Rebe wrote:
> 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.

> On: Sat, 11 Jan 2003 16:45:04 +0100,
>     Lionel Bouton <Lionel.Bouton@inet6.fr> wrote:
> > Soeren Sonnenburg wrote:
> > 
> > >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.
> 
> - René
> 
> --  
> René Rebe - Europe/Germany/Berlin
> e-mail:   rene.rebe@gmx.net, rene@rocklinux.org
> 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.

Re: choice of raid5 checksumming algorithm wrong ?

[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 ...

On: 11 Jan 2003 20:52:00 +0100,
    Soeren Sonnenburg <kernel@nn7.de> wrote:
> On Sat, 2003-01-11 at 20:39, Rene Rebe wrote:
> > 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.
> 
> > On: Sat, 11 Jan 2003 16:45:04 +0100,
> >     Lionel Bouton <Lionel.Bouton@inet6.fr> wrote:
> > > Soeren Sonnenburg wrote:
> > > 
> > > >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.
> > 
> > - René
> > 
> > --  
> > René Rebe - Europe/Germany/Berlin
> > e-mail:   rene.rebe@gmx.net, rene@rocklinux.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: choice of raid5 checksumming algorithm wrong ?

[Mr. James W. Laferriere]

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

On Sat, 11 Jan 2003, Rene Rebe wrote:
> 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 ...
-- 
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: choice of raid5 checksumming algorithm wrong ?

[Rene Rebe]

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),
    "Mr. James W. Laferriere" <babydr@baby-dragons.com> wrote:
> 
> 	Hello Rene , All ,  How about just printing the algorithm that is
> 	chosen & not the others ?  Just an idea .  JimL
> 
> On Sat, 11 Jan 2003, Rene Rebe wrote:
> > 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 ...
> -- 
>        +------------------------------------------------------------------+
>        | James   W.   Laferriere | System    Techniques | Give me VMS     |
>        | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
>        | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
>        +------------------------------------------------------------------+
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>