buggy raid checksumming selection?

buggy raid checksumming selection?

[Evaldo Gardenali]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Uhh. correct me if I am wrong, but shouldnt it select the fastest algorithm?

md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
~   8regs     :  2747.600 MB/sec
~   32regs    :  1702.000 MB/sec
~   pIII_sse  :  1997.200 MB/sec
~   pII_mmx   :  4216.400 MB/sec
~   p5_mmx    :  5408.000 MB/sec
raid5: using function: pIII_sse (1997.200 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
~ [events: 00000036]
~ [events: 00000036]
~ [events: 00000036]
md: autorun ...

Linux server1 2.4.25-pre6-athlonxp #1 Tue Jan 20 11:49:48 BRST 2004 i686
unknown unknown GNU/Linux
"-athlonxp" was added by me, just for identification purposes. NO other
sources except vanilla 2.4.24 and official 2.4.25-pre6 patch were involved

evaldo@server1:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(TM) XP 2200+
stepping        : 1
cpu MHz         : 1800.109
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips        : 3591.37

root@server1:~# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
00:0b.0 Ethernet controller: Macronix, Inc. [MXIC] MX987x5 (rev 20)
00:0c.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+]
(rev 44)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus
Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97
Audio Controller (rev 50)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II]
(rev 74)
root@server1:~#

Thanks
Evaldo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAESRl5121Y+8pAbIRAk8XAKClylSbg+Sht0lhWrIP9i1cjtb56gCeKBpv
ErxCiL4p5wrnAr4e4iEqU8M=
=wkDl
-----END PGP SIGNATURE-----

Re: buggy raid checksumming selection?

[John Bradford]

> Uhh. correct me if I am wrong, but shouldnt it select the fastest algorithm?

No.  This has been brought up on LKML in the past, search the archives
for extensive discussion of it.

John.

Re: buggy raid checksumming selection?

[Dave Jones]

On Fri, Jan 23, 2004 at 11:40:53AM -0200, Evaldo Gardenali wrote:

 > Uhh. correct me if I am wrong, but shouldnt it select the fastest algorithm?

No, if it can choose a function which avoids polluting the cache over
one that doesn't, it will.  Even if that means slightly less raw throughput

This comes up time after time, maybe we need a printk in that case ?

	Dave

Re: buggy raid checksumming selection?

[Nick Piggin]

Dave Jones wrote:

>On Fri, Jan 23, 2004 at 11:40:53AM -0200, Evaldo Gardenali wrote:
>
> > Uhh. correct me if I am wrong, but shouldnt it select the fastest algorithm?
>
>No, if it can choose a function which avoids polluting the cache over
>one that doesn't, it will.  Even if that means slightly less raw throughput
>
>This comes up time after time, maybe we need a printk in that case ?
>

How about removing the entire output? Is it really needed?

Re: buggy raid checksumming selection?

[Dave Jones]

On Sat, Jan 24, 2004 at 01:22:33AM +1100, Nick Piggin wrote:

 > >> Uhh. correct me if I am wrong, but shouldnt it select the fastest 
 > >algorithm?
 > >
 > >No, if it can choose a function which avoids polluting the cache over
 > >one that doesn't, it will.  Even if that means slightly less raw throughput
 > >
 > >This comes up time after time, maybe we need a printk in that case ?
 > 
 > How about removing the entire output? Is it really needed?

It's probably on a par with http://www.hadess.net/files/stuff/vpenis.c  8-)
You have a point though, it probably is pointless these days.

		Dave

Re: buggy raid checksumming selection?

[Ed Tomlinson]

On January 23, 2004 09:13 am, Dave Jones wrote:
> On Fri, Jan 23, 2004 at 11:40:53AM -0200, Evaldo Gardenali wrote:
>  > Uhh. correct me if I am wrong, but shouldnt it select the fastest
>  > algorithm?
>
> No, if it can choose a function which avoids polluting the cache over
> one that doesn't, it will.  Even if that means slightly less raw throughput

In this case it is half the throughput.  When is it reasonable to use the 
fast method?  If never, why even test it?

Ed

RE: buggy raid checksumming selection?

[Randal, Phil]

> On Fri, Jan 23, 2004 at 11:40:53AM -0200, Evaldo Gardenali wrote:
> 
>  > Uhh. correct me if I am wrong, but shouldnt it select the 
> fastest algorithm?
> 
> No, if it can choose a function which avoids polluting the cache over
> one that doesn't, it will.  Even if that means slightly less 
> raw throughput
> 
> This comes up time after time, maybe we need a printk in that case ?
> 
> 	Dave

I'm not suggesting that anyone waste any time over this, but are there any
"real world" benchmarks of the "fastest" vs "non cache-polluting"
algorithms.

Could there be any situations whereby even with cache-pollution we'd get
better performance?

I know it depends on the workload mix and amount of I/O, but...

Just curious.

Phil
---------------------------------------------
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK