On Sun, 19 Mar 2000, Martin Eriksson wrote:
> ----- Original Message -----
> From: "Michael Robinton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, March 19, 2000 9:54 AM
> Subject: raid parity and mmx processor
>
>
> > As I understand it, the kernel tests parity calc speed and decides to
> > use/not use mmx based on which is faster.
> >
> > Assuming an otherwise heavily loaded cpu, would it not be better to use
> > mmx even though slightly slower just to free up cpu cycles for other
> tasks.
>
> If you are doing the calculations faster, it takes shorter time before the
> CPU is free to do other things. Fastest is fastest.
>
Hmmm.... not really, if so, why would we have multi-processor systems.
mmx is a distinct processor apart from the fpp or main cpu. It is
possible for all to be doing separate operations at the same time.
i.e. gzip, raid parity, network traffic
> >
> > If I don't have the right picture here, someone please provide an
> > explaination of where the cpu cycles go to raid.
> >
> > This reason for my question is the amount of "nice" cycles on one of my
> > machines that is fairly busy. Only raid5d is niced, and I'm running a
> > load factor over one consistently with only about a 20% cpu load. It
> > appears most of the cpu cycles in use go to raid5 -- presumably parity
> > calculations.
>
> What kinda disks are you running on? SCSI? IDE? If IDE, do you have all nice
> things such as DMA transfers enabled?
>
IDE 33 +dma
> >
> > Assuming I'm not too far off base, it would be nice to have a /proc
> > option or at least a compile option to force use of mmx for raid parity
> > and a way to run the parity calculation test manually to see the
> difference
> > between the two methods.
>
> Maybe not for speed, but for bug tracing. Anyway, that would be good.
>
> >
