Date: Tue, 29 Mar 2016 14:25:55 -0700 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: fs@freebsd.org, rmacklem@freebsd.org Subject: Re: nfs pessimized by vnode pages changes Message-ID: <20160329212555.GP2616@FreeBSD.org> In-Reply-To: <20160329122721.D1549@besplex.bde.org> References: <20160327144755.Y4269@besplex.bde.org> <20160329090209.Q1020@besplex.bde.org> <20160329001623.GC2616@FreeBSD.org> <20160329122721.D1549@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 29, 2016 at 01:24:27PM +1100, Bruce Evans wrote:
B> > B> I couldn't get full-fs-block input to work right in ncl_getpages(). In
B> > B> the old version, vm_fault_hold() almost always calls it with the pages
B> > B> for exactly 1 full block, because vm_fault_additional_pages() somehow
B> > B> finds this many pages.
B> >
B> > The last quoted paragraph is a correct observation. According to your
B> > investigations, prior to r292373 NFS was doing multiple page pageins,
B> > despite it should have reported that it can't. My reading of the code
B> > is the same: both before r292373 and after r292373 NFS should page in
B> > a single page at request. I quickly reviewed the whole codepath and I
B> > can't see how with older code it was able to do multiple page pageins.
B>
B> I found it. In old versions, vm_fault_additional_pages() exists and
B> calls vnode_pager_haspage() to locate some additional pages.
B> VOP_BMAP() is vop_stdbmap() for nfs. This doesn't locate any
B> additional fs blocks, but vnode_pager_haspage() locates the page within
B> the single nfs block and returns the number of pages to read behind and
B> ahead to fill in the block.
Hmm, the code in vnode_pager_generic_getpages() after my change does pretty
much the same:
/* Recalculate blocks available after/before to pages. */
poff = (foff % bsize) / PAGE_SIZE;
before *= pagesperblock;
before += poff;
after *= pagesperblock;
after += pagesperblock - (poff + 1);
So, we got zeroes in 'after' and 'before' after vop_stdbmap. But here we
add 'poff' to them, which should yield in the same read sizes as before.
I will debug that.
--
Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160329212555.GP2616>