Re: mmap over nfs leads to excessive system load

[Andrew Morton <akpm@osdl.org>]

Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> On Wed, 2005-11-16 at 16:25 -0800, Andrew Morton wrote:
> > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > >
> > > The accompanying NFS patch makes use of this in order to figure out when
> > >  to flush the data correctly.
> > 
> > OK.  So with that patch, nfs_writepages() may still leave I/O pending,
> > uninitiated, yes?

This?

I don't know if it'll be a problem.  One factor is that when the VFS is
doing an fsync() or whatever, it will fail to notice these left-over pages
are "dirty", so it won't launch writepage() against them.

But if they are marked PageWriteback(), sync will notice them on the second
pass and will wait upon them, which apparently could mean a stall until
pdflush kicks off the I/O?

If they're not marked PageDirty() or PageWriteback(), the VFS will miss
them altogether during the sync.  But perhaps NFS's own page tracking will
flush them and wait upon the result?

> > I don't understand why NFS hasn't been BUGging as it stands at present.  It
> > has several end_page_writeback() calls but no set_page_writeback()s. 
> > end_page_writeback() or rotate_reclaimable_page() will go BUG if the page
> > wasn't PageWriteback().
> 
> It does have SetPageWriteback() calls in the asynchronous writeback
> path. As you can see from the patch I just sent, I only needed to
> replace them with set_page_writebacks().

Ah, OK.   Things are improved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/