From owner-freebsd-smp@FreeBSD.ORG Fri May 6 19:12:24 2005 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACDC416A4D4 for ; Fri, 6 May 2005 19:12:24 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7116043DA2 for ; Fri, 6 May 2005 19:12:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9DD65514C9; Fri, 6 May 2005 12:12:23 -0700 (PDT) Date: Fri, 6 May 2005 12:12:23 -0700 From: Kris Kennaway To: Allen Message-ID: <20050506191223.GB70068@xor.obsecurity.org> References: <20050506183529.GA46411@xor.obsecurity.org> <20050506184852.GA62656@xor.obsecurity.org> <6.2.1.2.2.20050506150138.036b83c0@mail.rfnj.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050506150138.036b83c0@mail.rfnj.org> User-Agent: Mutt/1.4.2.1i cc: smp@FreeBSD.org cc: Kris Kennaway Subject: Re: Benchmarking mpsafevfs with parallel tarball extraction X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 19:12:24 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3D/dev/zero of=3D/dev/md0 bs=3D1024k count=3D500 > >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). >=20 > That looks pretty goofy. Even PC66 SDRAM should be able to push ~250MB/s= =20 > on a very slow processor. Does the md code for raw access really load th= is=20 > 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: >=20 > Part of me wants to think that maybe this is due to some fashion of=20 > metadata caching, in the manner of softupdates. Possible? Well, softupdates is disabled, but maybe there's something else going on. Kris --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCe8GXWry0BWjoQKURApIvAKDLP3b883E2/rBRQK0VPAc4AvAndwCggYs4 llGOYKcE8TYGA0J/4UiMDo8= =Z5zz -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY--