From owner-svn-src-all@FreeBSD.ORG Tue May 7 07:41:15 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 342362E8; Tue, 7 May 2013 07:41:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9E508630; Tue, 7 May 2013 07:41:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r477f3ln091620; Tue, 7 May 2013 10:41:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r477f3ln091620 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r477f2m1091618; Tue, 7 May 2013 10:41:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 May 2013 10:41:02 +0300 From: Konstantin Belousov To: Scott Long Subject: Re: svn commit: r250027 - head/sys/kern Message-ID: <20130507074102.GE3047@kib.kiev.ua> References: <201304281912.r3SJC9bL030636@svn.freebsd.org> <20130506181610.GA1390@garage.freebsd.pl> <20130506200530.GD3047@kib.kiev.ua> <166D5005-9B80-4B72-BF6C-80DA0F5D6DCD@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1nHxr/DJDVCa1lM8" Content-Disposition: inline In-Reply-To: <166D5005-9B80-4B72-BF6C-80DA0F5D6DCD@yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 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, 07 May 2013 07:41:15 -0000 --1nHxr/DJDVCa1lM8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2013 at 01:04:35AM -0600, Scott Long wrote: >=20 > On May 6, 2013, at 2:05 PM, Konstantin Belousov wro= te: >=20 > > On Mon, May 06, 2013 at 08:16:11PM +0200, Pawel Jakub Dawidek wrote: > >> On Sun, Apr 28, 2013 at 07:12:09PM +0000, Konstantin Belousov wrote: > >>> Author: kib > >>> Date: Sun Apr 28 19:12:09 2013 > >>> New Revision: 250027 > >>> URL: http://svnweb.freebsd.org/changeset/base/250027 > >>>=20 > >>> Log: > >>> Eliminate the layering violation in the kern_sendfile(). When queri= ng > >>> the file size, use VOP_GETATTR() instead of accessing vnode vm_object > >>> un_pager.vnp.vnp_size. > >>=20 > >> Doesn't it add extra I/O to query file system about file's attributes? > >> If it does, does it matter here? > >=20 > > It should not, typically. >=20 > Whenever you say the word "typically", I get nervous. I take this to > mean that under pressure, the syscall may likely synchronously block > to complete this call. If so, then it makes sendfile() pretty much > unusable for us at Netflix, and it means that we will either need to > revert this or resort to a hack. Typical there is quantified by the filesystem type. If you read my previous response, you should note that I claimed that UFS never performs disk access when executing VOP_GETATTR(). The UFS inode is always kept in memory while vnode is not reclaimed. For NFS indeed, if the attribute cache is expired, the rpc is fired. >=20 > >=20 > > E.g. UFS always keeps the unpacked inode in memory for any non-reclaimed > > vnode. For NFS, vnode usually caches the attributes. > >=20 > > Anyway, using VOP_GETATTR() is the only sanctioned way to get file size. > > Directly accessing vm_object assumes that vm_object is of OBJT_VNODE ty= pe, > > which is no longer true. >=20 > How about just testing for this assumption and only performing the VOP_GE= TATTR > if it's not true? This might be done, I will look at this later. --1nHxr/DJDVCa1lM8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRiLANAAoJEJDCuSvBvK1BAg8P+wfQKw+k1/P3aJi1N4poglK/ 7oIR8xMg1xqz1rVjS25lCIMAB8/E5TmGfvJSUULo1aymKD2LIA20K41M08scQbC2 j/vq3tcKxAmNACGNccYiSOaA6rsVQjeq7xCiPUZ8Kbk5uVcLoSezjvwY3RX5BxPF A+/qtxMSbww3ScQ2X9sExNXQAYuIqJF7ICIbfAW5qUYrF8+tRu8/oO6W0FFJ0n0d +uD8cbiUO2W058uJhrxw8/cPPLcCh9dVwowvCWuRm8RmL7T3ZEVfDshY3YtmrxqL V//xsZVFv5YVg0p2OtagVHWLiU5QanxObFge+sGZMfcnI++lBLMbRju+k1MMU7BF M1TIuh3csijaQtv7XPVFfFJ/a1CqpZtCdR+y7Ovre0hZF3cdZ2AS6U3dszufVbtS cu5FLU7KfZ9aOb9g7wS9sAS3917fEyU9XiwA1aE2wCNebgkaX/kG8x5mgsDAY+s2 wD23Vr8sWVpON7GVQITAXkuTxwkMMnRYnED5hfbs45YfXyowYzJJxVqV8W425mmf Sirj0agortK/ZjYg6VTG8KjbQRQkSiecCFjnW7gFfXWmnY2u/n2gvjy2je2wkJiV 4giXvd6Bw0W99UveU6GMy/9Rp3HYjklVBX5jOAbLAkxhZ83O5dhO04DxR/OJZWT3 KLLf9J6JWrmScuJE/xBN =KlTg -----END PGP SIGNATURE----- --1nHxr/DJDVCa1lM8--