From owner-svn-src-all@FreeBSD.ORG Tue May 7 07:04:43 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 EAE2F864 for ; Tue, 7 May 2013 07:04:43 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm17.bullet.mail.bf1.yahoo.com (nm17.bullet.mail.bf1.yahoo.com [98.139.212.176]) by mx1.freebsd.org (Postfix) with SMTP id 8E84C2CC for ; Tue, 7 May 2013 07:04:43 +0000 (UTC) Received: from [98.139.215.140] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2013 07:04:35 -0000 Received: from [98.139.213.6] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2013 07:04:35 -0000 Received: from [127.0.0.1] by smtp106.mail.bf1.yahoo.com with NNFMP; 07 May 2013 07:04:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1367910275; bh=It8LGqfZ/xzFqAIwVEbBH/t6h7s4fFpgbsmlDJ1pwDY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=2nGaQMsj+DF/r5KYYL9h/04jGtksRi0ClACEqvXPutNr5NoCYJgvyFnubC9NHw3oIdRGrYcMgtDOYsFGAQJRDNUfbYy0LQ/7ei4d0fa9iBKWOSamx3RxHQfBZklLVKKF6LdugVbUguCMC4kowOOQIO19XGfpo5bI9ZLex/Yjwjk= X-Yahoo-Newman-Id: 854853.4454.bm@smtp106.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: x2RaBcUVM1nMIdWwgkTRl.U62XhcQkYu_apUHbYmJUJ5s1w Ytj70v.J.tHcj5dACB7ltExWkUWCgfzmCm_T0XJYH4MirJO8KgsqbG06JvPO 5UONfneXv_voALRW2qUvxEQaHDNY_8RG5TtbqEq2NBD9NIMaJLciXjc4qHg2 kTkE0J9nuFnciSIKD6UtedfixCXEC3OS4FNE5rWQbGTEmoGjqyNQkBgvuVqx kMUCpfo3gMt0yJoif4VxmEGauCcESBuSM82gCBAIuTkvX6vx4rk.SNwP2TrT 6IxQuyjuu9gkWA.6hP_AY.gadVzpaOBfe_xORzJhQaxkjhOGiA02eHc9MR5Z 7OXMQxI2CxKBNshxd3noNdgWg3978wZ_T1z4zumr4xwqeeQILIDm9RfVte2P CgV7E7Gz2AEp6nUaF1DQcFGKEBNo24fjhdzfbOKBz8PY0Sj0gQeiWnifuc9j JJQkfEF8Qeq5WC6gsjit7hG7zJ2xhSxBSVZVLCBxyMP.p91SDfm.YKuwLvXH eVJf2u.y52l8v6URvam6Q7UZ9mYVW_NgaiZPI8johuB3Nytc- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.samsco.home (scott4long@168.103.85.57 with ) by smtp106.mail.bf1.yahoo.com with SMTP; 07 May 2013 00:04:35 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: svn commit: r250027 - head/sys/kern From: Scott Long In-Reply-To: <20130506200530.GD3047@kib.kiev.ua> Date: Tue, 7 May 2013 01:04:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <166D5005-9B80-4B72-BF6C-80DA0F5D6DCD@yahoo.com> References: <201304281912.r3SJC9bL030636@svn.freebsd.org> <20130506181610.GA1390@garage.freebsd.pl> <20130506200530.GD3047@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1503) 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:04:44 -0000 On May 6, 2013, at 2:05 PM, Konstantin Belousov = wrote: > 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 = quering >>> 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. 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. >=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 = type, > which is no longer true. How about just testing for this assumption and only performing the = VOP_GETATTR if it's not true? Scott