From owner-svn-src-all@freebsd.org Tue Feb 26 05:46:44 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53B4D150C2E4; Tue, 26 Feb 2019 05:46:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id B78786C5EC; Tue, 26 Feb 2019 05:46:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id F2FB310555F4; Tue, 26 Feb 2019 16:46:40 +1100 (AEDT) Date: Tue, 26 Feb 2019 16:46:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Jason A. Harmening" cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344562 - head/sys/ufs/ffs In-Reply-To: <201902260456.x1Q4uAIu056382@repo.freebsd.org> Message-ID: <20190226162300.M1437@besplex.bde.org> References: <201902260456.x1Q4uAIu056382@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=P1rLNQFAf2zFqKBdL3UA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: B78786C5EC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.83 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.83)[-0.833,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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, 26 Feb 2019 05:46:44 -0000 On Tue, 26 Feb 2019, Jason A. Harmening wrote: > ... > Log: > FFS: allow sendfile(2) to work with block sizes greater than the page size > > Implement ffs_getpages_async(), which when possible calls the asynchronous > flavor of the generic pager's getpages function. When the underlying > block size is larger than the system page size, however, it will invoke > the (synchronous) buffer cache pager, followed by a call to the client > completion routine. This retains true asynchronous completion in the most > common (block size <= page size) case, which is important for the performance > of the new sendfile(2). The behavior in the larger block size case mirrors > the default implementation of VOP_GETPAGES_ASYNC, which most other > filesystems use anyway as they do not override the getpages_async method. block_size <= PAGE_SIZE is very uncommon for ffs, even on systems with large pages. MINBSIZE is 4096 in ffs (except in my version, it is 512). The default is 32768 in newfs. I consider this excessive and only use it for file systems with many files larger than 1GB, but it is the most common size. It is larger than the large page size of 8192. ffs_getpages() already has an almost-never-used special case for small block sizes. It uses vnode_pager_generic_getpages() when !use_buf_pager and the block_size <= PAGE_SIZE, else vfs_bio_getpages(). But block_size <= PAGE_SIZE is unusual, and !use_buf_pager is also unusual, and use_buf_pager is mostly a debugging sysctl, so little would be lost but using vfs_bio_getpages() unconditionally. Bruce