Date: Tue, 31 May 2011 16:19:12 -0700 From: mdf@FreeBSD.org To: Pieter de Goeje <pieter@degoeje.nl>, Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r221853 - in head/sys: dev/md dev/null sys vm Message-ID: <BANLkTikvVQd1pRtK%2B06SreAcEGbxuwdzSQ@mail.gmail.com> In-Reply-To: <BANLkTi=o_NUTN1wABx3_7GnUgXUs3divcQ@mail.gmail.com> References: <201105131848.p4DIm1j7079495@svn.freebsd.org> <201105282103.43370.pieter@degoeje.nl> <BANLkTimJY65boMPhnnT344cmwRUJ0Z=dSQ@mail.gmail.com> <201105312348.59571.pieter@degoeje.nl> <BANLkTi=o_NUTN1wABx3_7GnUgXUs3divcQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 31, 2011 at 3:47 PM, <mdf@freebsd.org> wrote: > On Tue, May 31, 2011 at 2:48 PM, Pieter de Goeje <pieter@degoeje.nl> wrot= e: >> On Sunday 29 May 2011 05:01:57 mdf@freebsd.org wrote: >>> On Sat, May 28, 2011 at 12:03 PM, Pieter de Goeje <pieter@degoeje.nl> w= rote: >>> > To me it looks like it's not able to cache the zeroes anymore. Is thi= s >>> > intentional? I tried to change ZERO_REGION_SIZE back to 64K but that >>> > didn't help. >>> >>> Hmm. =A0I don't have access to my FreeBSD box over the weekend, but I'l= l >>> run this on my box when I get back to work. >>> >>> Meanwhile you could try setting ZERO_REGION_SIZE to PAGE_SIZE and I >>> think that will restore things to the original performance. >> >> Indeed it does. I couldn't find any authoritative docs stating wether or= not >> the cache on this CPU is virtually indexed, but apparently at least some= of >> it is. > > On my physical box (some Dell thing from about 2008), I ran 10 loops > of dd if=3D/dev/zero of=3D/dev/null bs=3DXX count=3DXX where bs went by p= owers > of 2 from 512 bytes to 2M, and count was set so that the dd always > transferred 8GB. =A0I compared ZERO_REGION_SIZE of 64k and 2M on amd64. > > The summary of the ministat(1) output is: > > bs=3D512b - no difference > bs=3D1K - no difference > bs=3D2k - no difference > bs=3D4k - no difference > bs=3D8k - no difference > bs=3D16k - no difference > bs=3D32k - no difference > bs=3D64k - no difference > bs=3D128k - 2M is 0.69% faster > bs=3D256k - 2M is 0.98% faster > bs=3D512k - 2M is 0.65% faster > bs=3D1M - 2M is 1.02% faster > bs=3D2M - 2M is 2.17% slower > > I'll play again with a 4K buffer. The data is harder to parse precisely, but in general it looks like on my box using a 4K buffer results in significantly worse performance when the dd(1) block size is larger than 4K. How much worse depends on the block size, but it goes from 6% at bs=3D8k to 17% at bs>=3D256k. Showing 4k/64k/2M ZERO_REGION_SIZE graphically in the ministat(1) output also makes it clear that the difference between 64k and 2M is nearly insignificant on my box compared to using 4k. http://people.freebsd.org/~mdf/zero-ministat.txt Cheers, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikvVQd1pRtK%2B06SreAcEGbxuwdzSQ>