From owner-freebsd-stable@FreeBSD.ORG Fri Oct 29 22:59:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EBBF106564A for ; Fri, 29 Oct 2010 22:59:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EB7CB8FC08 for ; Fri, 29 Oct 2010 22:59:55 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9TMxpGS044681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Oct 2010 01:59:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9TMxpIL033834; Sat, 30 Oct 2010 01:59:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9TMxp6H033833; Sat, 30 Oct 2010 01:59:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Oct 2010 01:59:51 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101029225951.GZ2392@deviant.kiev.zoral.com.ua> References: <4CCACDC0.7050802@icyb.net.ua> <1BDB4D1B02274CC8AA2DD5E68190CB5D@vosz.local> <20101029145349.GX2392@deviant.kiev.zoral.com.ua> <4CCAE2B6.1050906@icyb.net.ua> <20101029151727.GY2392@deviant.kiev.zoral.com.ua> <4CCAE6CE.9020509@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YvLLLzhFN3pBahCG" Content-Disposition: inline In-Reply-To: <4CCAE6CE.9020509@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, Alexander Zagrebin Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 22:59:56 -0000 --YvLLLzhFN3pBahCG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 29, 2010 at 06:22:54PM +0300, Andriy Gapon wrote: > on 29/10/2010 18:17 Kostik Belousov said the following: > > On Fri, Oct 29, 2010 at 06:05:26PM +0300, Andriy Gapon wrote: > >> on 29/10/2010 17:53 Kostik Belousov said the following: > >>> Could it be the priming of the vm object pages content ? > >> > >> Sorry, not familiar with this term. > >> Do you mean prepopulation of vm object with valid pages? > >> > >>> Due to double-buffering, and (possibly false) optimization to only > >> > >> What optimization? > > On zfs vnode read, the page from the corresponding vm object is only > > populated with the vnode data if the page already exists in the > > object. >=20 > Do you mean a specific type of read? > For "normal" reads it's the other way around - if the page already exists= and is > valid, then we read from the page, not from ARC. Let me repeat it once more: zfs does not properly caches the vnode data content in the page cache (the cache is used in a weaker sence, not meaning the freebsd 'cached' memory, but a cache in more common sence). Not doing the optimization I mentioned would mean always allocating the pages and making it (partially) valid for each read call. >=20 > > Not doing the optimization would be to allocate the page uncoditionally > > on the read if not already present, and copy the data from ARC to the p= age. > >> > >>> perform double-buffering when vm object already has some data cached, > >>> reads can prime vm object page list before file is mmapped or > >>> sendfile-ed. > >>> > >> > >> No double-buffering is done to optimize anything. Double-buffering > >> is a consequence of having page cache and ARC. The special > >> "double-buffering code" is to just handle that fact - e.g. making > >> sure that VOP_READ reads data from page cache instead of ARC if it's > >> possible that the data in them differs (i.e. page cache has more > >> recent data). > >> > >> So, if I understood the term 'priming' correctly, no priming should > >> ever occur. > > The priming is done on the first call to VOP_READ() with the right > > offset after the page is allocated. >=20 > Again, what is priming? Filling the cache with an appropriate content. --YvLLLzhFN3pBahCG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzLUecACgkQC3+MBN1Mb4gh8wCeIlW79u45lF5hA/a6C4kVz90V qDQAn1k3WXZQj6KMeT2XfZiG+lfSRu2x =J/ZR -----END PGP SIGNATURE----- --YvLLLzhFN3pBahCG--