Benchmarking mpsafevfs with parallel tarball extraction

[Kris Kennaway]

On Fri, May 06, 2005 at 03:11:39PM -0400, Allen wrote:
> At 14:48 5/6/2005, Kris Kennaway wrote:
> >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??

It must be something specific to the machine or architecture, because
others have posted md speeds an order of magnitude faster than this
(e.g. on amd64).

> >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?

Well, softupdates is disabled, but maybe there's something else going
on.

Kris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-smp/attachments/20050506/0a583ef6/attachment.bin