Date: Fri, 22 Dec 2006 05:45:35 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Mark Kirkwood <markir@paradise.net.nz> Cc: Pieter de Goeje <pieter@degoeje.nl>, freebsd-stable@freebsd.org Subject: Re: Cached file read performance with 6.2-PRERELEASE Message-ID: <20061221184535.GF41566@turion.vk2pj.dyndns.org> In-Reply-To: <458A606E.6080008@paradise.net.nz> References: <45888C68.10305@paradise.net.nz> <200612200816.51043.joao@matik.com.br> <4589128F.9030404@paradise.net.nz> <200612201536.25497.pieter@degoeje.nl> <458A606E.6080008@paradise.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
--Pgaa2uWPnPrfixyx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2006-Dec-21 23:22:38 +1300, Mark Kirkwood wrote: >Pieter de Goeje wrote: >>On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote: >>>In fact if you note that the PIII HW *can* actually do 700MB/s, it >>>suggests that your HW is capable of considerably more than 900MB/s - >>>given that opteron's have excellent cpu to memory bandwidth, and the >>>speed of your memory! >>Indeed! >>Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz= =20 >>Athlon64. It imagine there are quite a few extra things done when copying= =20 >>a file from cache, because I can only manage to get one fifth (~1GB/sec)= =20 >>of the theoretical speed. (this is with a file that fills more than half= =20 >>of all memory) > >Fascinating, never thought of trying that! On my 2 (essentially)=20 >identical PIII systems, doing copy /dev/zero to /dev/null yields 4.1=20 >GB/s (Gentoo) and 2.0GB/s (FreeBSD) - so yeah, clearly both do=20 >something special in that case... (growl... we - i.e FreeBSD - seem to=20 >be slower again...tho at that sort of rate, who cares!) This appears to be a fairly meaningless test: I don't know of any applications that rely on /dev/zero read speed or /dev/null write speed. And I don't think we should fuss overly much about claims that Linux can do nothing twice as fast as FreeBSD. If this was really an important issue, we could patch our libc to recognize special filenames and avoid doing syscalls at all on I/O to /dev/zero or /dev/null - this would give us a totally meaningless performance boost. I agree that the FS cache read speed is an issue but the common code paths between filesystem reads and /dev/zero reads are copyout(9) and the generic system call overhead. Before claiming that they are the culprits, someone needs to get some more detailed performance figures (via hwpmc or kernel profiling) and find where the time is really spent. --=20 Peter Jeremy --Pgaa2uWPnPrfixyx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFitZP/opHv/APuIcRAkwzAJ49yEqvpbrK0BhULRR40YBcdsGzFQCfbzzO nciUVdQPrkPakmuCZqnkyBM= =Wr5r -----END PGP SIGNATURE----- --Pgaa2uWPnPrfixyx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061221184535.GF41566>