Re: 2.6.6-rc{1,2} bad VM/NFS interaction in case of dirty page writeback

[Nick Piggin]

Andrew Morton wrote:
> Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote:
>
> > On Mon, 2004-04-26 at 22:15, Andrew Morton wrote:
> >
> > > WRITEPAGE_ACTIVATE is a bit of a hack to fix up specific peculiarities of
> > > the interaction between tmpfs and page reclaim.
> > >
> > > Trond, the changelog for that patch does not explain what is going on in
> > > there - can you help out?
> >
> > As far as I understand, the WRITEPAGE_ACTIVATE hack is supposed to allow
> > filesystems to defer actually starting the I/O until the call to
> > ->writepages(). This is indeed beneficial to NFS, since most servers
> > will work more efficiently if we cluster NFS write requests into "wsize"
> > sized chunks.
>
>
> No, it's purely used by tmpfs when we discover the page was under mlock or
> we've run out of swapspace.
>
> Yes, single-page writepage off the LRU is inefficient and we want
> writepages() to do most of the work.  For most workloads, this is the case.
> It's only the whacky mmap-based test which should encounter significant
> amounts of vmscan.c writepage activity.

Nikita has a patch to gather a page's dirty bits before
taking it off the active list. It might help here a bit.
Looks like it would need porting to the new rmap stuff.

>  If you're seeing much traffic via
> that route I'd be interested in knowing what the workload is.
>
> There's one scenario in which we _do_ do too much writepage off the LRU,
> and that's on 1G ia32 highmem boxes: the tiny highmem zone is smaller than
> dirty_ratio and vmscan ends up doing work which balance_dirty_pages()
> should have done.  Hard to fix, apart from reducing the dirty memory
> limits.

You might be able to improve this by not allocating the
highmem zone right down to its scanning watermark while
zone normal has lots of free memory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/