Date: Tue, 26 Feb 2019 16:46:40 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "Jason A. Harmening" <jah@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344562 - head/sys/ufs/ffs Message-ID: <20190226162300.M1437@besplex.bde.org> In-Reply-To: <201902260456.x1Q4uAIu056382@repo.freebsd.org> References: <201902260456.x1Q4uAIu056382@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190226162300.M1437>