Date: Fri, 06 May 2005 15:11:39 -0400 From: Allen <bsdlists@rfnj.org> To: Kris Kennaway <kris@obsecurity.org> Cc: smp@FreeBSD.org Subject: Re: Benchmarking mpsafevfs with parallel tarball extraction Message-ID: <6.2.1.2.2.20050506150138.036b83c0@mail.rfnj.org> In-Reply-To: <20050506184852.GA62656@xor.obsecurity.org> References: <20050506183529.GA46411@xor.obsecurity.org> <20050506184852.GA62656@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?? >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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.1.2.2.20050506150138.036b83c0>