On Fri, May 06, 2005 at 11:35:29AM -0700, Kris Kennaway wrote:
> I might be bumping into the bandwidth of md here - when I ran less > rigorous tests with lower concurrency of extractions I seemed to be > getting marginally better performance (about an effective concurrency > of 2.2 for both 3 and 10 simultaneous extractions - so at least it > doesn't seem to degrade badly). Or this might be reflecting VFS lock > contention (which there is certainly a lot of, according to mutex > profiling traces).
I suspect that I am hitting the md bandwidth:
# dd if=/dev/zero of=/dev/md0 bs=1024k count=500 500+0 records in 500+0 records out 524288000 bytes transferred in 9.501760 secs (55177988 bytes/sec)
which is a lot worse than I expected (even for a 400MHz CPU).
That looks pretty goofy. Even PC66 SDRAM should be able to push ~250MB/s on a very slow processor. Does the md code for raw access really load this much work onto the CPU??
For some reason I get better performance writing to a filesystem mounted on this md:
Part of me wants to think that maybe this is due to some fashion of metadata caching, in the manner of softupdates. Possible?
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-smp To unsubscribe, send any mail to "[EMAIL PROTECTED]"
