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 _at_ 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> > -- > RenRebe - Europe/Germany/Berlin > e-mail: rene.rebe _at_ gmx.net, rene _at_ 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 _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups: References:
- Re: choice of raid5 checksumming algorithm wrong ?Lionel Bouton
- Re: choice of raid5 checksumming algorithm wrong ?Rene Rebe
- Prev by Date: 2.5.56 changelog entry
- Next by Date: [2.4 patch] update help for hpt366.c
- Previous by thread: Re: choice of raid5 checksumming algorithm wrong ?
- Next by thread: Re: choice of raid5 checksumming algorithm wrong ?
- Indexes:[Main][Thread]