Re: nfs unhappiness with memory pressure

[Nick Piggin <nickpiggin@yahoo.com.au>]

Trond Myklebust wrote:
> On Mon, 2005-12-05 at 16:18 -0500, Trond Myklebust wrote:
> 
>>On Tue, 2005-12-06 at 07:52 +1100, Nick Piggin wrote:
>>
>>
>>>The VM doesn't expect to have to rely on pdflush to write out pages
>>>for it. ->writepage should be enough. Adding wakeup_pdflush here
>>>actually could do the wrong thing for non-NFS filesystems if it
>>>starts more writeback.
>>
>>nr_unstable is not going to be set for non-NFS filesystems. 'unstable'
>>is a caching state in which pages have been written out to the NFS
>>server, but the server has not yet flushed the data to disk.
> 

But if you have NFS and non-NFS filesystems, wakeup_pdflush isn't
always going to do the right thing.

> 
> ...and most important of all: 'unstable' does _not_ mean that I/O is
> active on those pages (unlike the apparent assumption in
> vm_throttle_write.
> That is why the choice is either to kick pdflush there, or to remove
> nr_unstable from the accounting in that loop.
> 

Doesn't matter if IO is actually active or not, if you've allocated
memory for these unstable pages, then page reclaim can scan itself
to death, which is what seems to have happened here. And which is
what vm_throttle_write is supposed to help.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com