Fedora SMP dual core, dual AMD 64 processor system

[Mark Hahn]

> > sure, but so what?  so SW raid will need to transfer a few extra 
> > chunks over some of the 8GB/s HT channels, among some of the 
> > 26 GB/s of memory bandwidth available.
> 
> I didn't know Opterons could distribute the I/O operations across CPUs
> to use all that memory bandwidth.  You're throwing around theoretical
> and aggregate maximums like that's actually what you're going to get.

opterons can certainly have peripherals attached to multiple CPUs;
this is normal for nvidia-based systems, and certainly possible with
the AMD chipset.

> > why do you think that a few hundred MB/s out of many GB/s is going
> > to make a difference?
> 
> Yes, when you're moving those MBs through the CPU and turning it all
> into one huge Programmed I/O (PIO) operation.  You're not going to get

a stream of very brief block memory operations.

> GBps in transfers.  You're losing valuable chunks of time and,
> therefore, cutting cycles away from transfer time as well.

again, since the host can do the xor at several GB/s, a trickle 
of them at 250 MB/s just doesn't amount to much.

> Again, if it takes up 50% of your cycles just to push hundreds of MBs

again, 5% is about right, for an otherwise idle cpu.

> > how strange!  what on earth do you think you can do with disks
> > at 4 GB/s?  or are you worried about streaming reads from ~50
> > disks at once?
> 
> But you're not getting 4GBps.  At this point, I need to bow out of this
> discussion.  It's obvious that you believe you can push 8GB of data
> through your CPU in a second.

Stream says it only takes 3 cpus to push 8GB/s; that's triad, which
is more CPU-intense than R5.  that's also not counting write-allocate
traffic, or using prefetchnta.  similarly 4GB/s is correct, even low
for a dual.