From owner-svn-src-all@FreeBSD.ORG Tue May 31 23:19:15 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C918D106564A; Tue, 31 May 2011 23:19:14 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 00BF58FC0C; Tue, 31 May 2011 23:19:13 +0000 (UTC) Received: by wyf23 with SMTP id 23so5018544wyf.13 for ; Tue, 31 May 2011 16:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mWj+DB+0wxj5iLji7t9a+XU0A1WeaPrNNtXslm1FrU4=; b=K95dnxd3K7PN4EXOeIgUAoUCzzUfWOkc0madHeaA2iF6XEUL1yhq2I38I3D2GH53NW 1XyWpe5zFtO0eQxxDDbqr8T9VYGQu4c5APk2mqsHSqDWb3Luf+4cu9A9frHOk1ZAr+rb z0Gr6peZuuMQ4hPDgTdj8fZff4amoWkWAQj20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Sq4f0vkR2VCBtuCHNnAoGNLE4qASnjhmmnr660XQg5DvkXatbnJ4d36JhxCQBFn93Z RSqii0XP1jX3D9GNlrNByMEmluHHZvbHj9WpEvbmMW4jtkgSmclpMW3FDzYzPSeWzwvu wbLx8xSW5O7vCp7SNDpBFtj0WiytTWlcmK4Lw= MIME-Version: 1.0 Received: by 10.216.156.70 with SMTP id l48mr4209655wek.5.1306883952742; Tue, 31 May 2011 16:19:12 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.93.193 with HTTP; Tue, 31 May 2011 16:19:12 -0700 (PDT) In-Reply-To: References: <201105131848.p4DIm1j7079495@svn.freebsd.org> <201105282103.43370.pieter@degoeje.nl> <201105312348.59571.pieter@degoeje.nl> Date: Tue, 31 May 2011 16:19:12 -0700 X-Google-Sender-Auth: 2SLuOfVHH6Et4RI3D8_JQMfByAY Message-ID: From: mdf@FreeBSD.org To: Pieter de Goeje , Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:19:15 -0000 On Tue, May 31, 2011 at 3:47 PM, wrote: > On Tue, May 31, 2011 at 2:48 PM, Pieter de Goeje 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 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