Trond Myklebust <[email protected]> wrote:
>
> On Wed, 2005-11-16 at 11:09 -0800, Andrew Morton wrote:
> > Trond Myklebust <[email protected]> wrote:
> > >
> > > On Wed, 2005-11-16 at 10:00 -0800, Andrew Morton wrote:
> > >
> > > > That will fix it, but the PageWriteback accounting is still wrong.
> > > >
> > > > Is it not possible to use set_page_writeback()/end_page_writeback()?
> > >
> > > Not really. The pages aren't flushed at this time. We the point is to
> > > gather several pages and coalesce them into one over-the-wire RPC call.
> > > That means we cannot really do it from inside ->writepage().
> > >
> >
> > I still don't get it.
> >
> > Once nfs_writepage() has been called, the page is conceptually "under
> > writeback", yes? In that, at some point in the future, it will be written
> > to backing store.
> >
> > Hence it's perfectly appropriate to run set_page_writepage() within
> > nfs_writepage(). It's a matter of finding the right place for the
> > end_page_writeback().
>
> The point is that the process of flushing has not been started at that
> time, so anybody that calls wait_on_page_writeback() immediately after
> calling writepage() may end up waiting for a very long time indeed
> (probably until the next pdflush).
But block-backed filesytems have the same concern: we don't want to do a
whole bunch of 4k I/Os. Hence the writepages() interface, which is the
appropriate place to be building up these large I/Os.
NFS does nfw_writepages->mpage_writepages->nfs_writepage and to build the
large I/Os it leaves the I/O pending on return from nfs_writepage(). It
appears to flush any pending pages on the exit path from nfs_writepages().
If that's a correct reading then there doesn't appear to be any way in
which there's dangling I/O left to do after nfs_writepages() completes.
If there _is_ dandling I/O left over then that's problematic, and probably
doesn't buy us much in the way of performance benefit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
