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.
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.
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 <[email protected]> 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: [email protected], [email protected]
web: http://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.
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 <[email protected]> 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: [email protected], [email protected]
> web: http://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.
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 <[email protected]> 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 <[email protected]> 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: [email protected], [email protected]
> > web: http://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/
>
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 |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
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" <[email protected]> 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 |
> | [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/
>