Date: Mon, 30 Jul 2007 21:26:54 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Dominic Bishop <dom@bishnet.net> Cc: geom@FreeBSD.org Subject: Re: Increasing GELI performance Message-ID: <20070730192654.GO1092@garage.freebsd.pl> In-Reply-To: <20070727210032.0140413C457@mx1.freebsd.org> References: <46AA50B4.9080901@fluffles.net> <20070727210032.0140413C457@mx1.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--fNagykWcDoSVAmSd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2007 at 10:00:35PM +0100, Dominic Bishop wrote: > I just tried your suggestion of geli on the raw device and it is no better > at all: >=20 > dd if=3D/dev/da0.eli of=3D/dev/null bs=3D1m count=3D1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 29.739186 secs (35259069 bytes/sec) >=20 > dd if=3D/dev/zero of=3D/dev/da0.eli bs=3D1m count=3D1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 23.501061 secs (44618241 bytes/sec) >=20 > Using top -S with 1s refresh to list the geli processes whilst doing this= it > seems only one of them is doing anything at any given time, the others are > sitting in a state of "geli:w", I assume that is a truncation of somethin= g, > maybe geli:wait at a guess. No matter how many cores/cpus you have if you run single-threaded application. What you do exactly is: 1. Send read of 128kB. 2. One of geli threads picks it up, decrypts and sends it back. 3. Send next read of 128kB. 4. One of geli threads picks it up, decrypts and sends it back. =2E.. All threads will be used when there are more threads accessing provider. > For comparison, here are the same tests done on the unencrypted raw devic= e: >=20 > dd if=3D/dev/da0 of=3D/dev/null bs=3D1m count=3D1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 5.802704 secs (180704717 bytes/sec) >=20 > dd if=3D/dev/zero of=3D/dev/da0 bs=3D1m count=3D1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 4.026869 secs (260394859 bytes/sec) You can see how much CPU power your one core has by doing something like this: # kldload geom_zero # geli onetime -s 4096 gzero # sysctl kern.geom.zero.clear=3D0 # dd if=3D/dev/gzero.eli of=3D/dev/null bs=3D1m count=3D4096 /dev/gzero is similar to /dev/zero, but it is a GEOM provider. This experiment will show you how much encryption throughput you can get from one geli thread, without disk overhead. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --fNagykWcDoSVAmSd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGrjt+ForvXbEpPzQRAg6sAJsHLS1W5ZZVjdXmW1uuPJEzgKoylgCfX8wy 5DupTlMsgJZjhdKcApiNLEU= =Iq2i -----END PGP SIGNATURE----- --fNagykWcDoSVAmSd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070730192654.GO1092>