Date: Tue, 6 Dec 2005 14:36:31 +1100
From: Andrew Morton <akpm@osdl.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: theonetruekenny@yahoo.com, linux-kernel@vger.kernel.org
Subject: Re: nfs unhappiness with memory pressure
Message-Id: <20051206143631.08b4e8e6.akpm@osdl.org>
In-Reply-To: <1133822367.8003.5.camel@lade.trondhjem.org>
References: <20051205210442.17357.qmail@web34106.mail.mud.yahoo.com>
	<1133822367.8003.5.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1233
Lines: 27

Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> Argh... Not sure entirely how to deal with that... We definitely don't
>  want the thing futzing around inside throttle_vm_writeout(), 'cos
>  writeout isn't going to happen while the socket blocks.
> 

As far as the core VM is concerned, these pages are really "dirty", only it
happens to be a different flavour of dirtiness.  So perhaps we should
continue to mark these pages as dirty and let NFS internally take care
of which end of the wire they're dirty at.

Presumably calling writepage() a second time won't be very useful.  Or will
it?  Perhaps when NFS sees writepage against a PageDirty && PageUnstable
page it can recognise that as a hint to kick off a server-side write.

>  ...OTOH, I'm not entirely sure we want to use GFP_ATOMIC and risk
>  bleeding the emergency pools dry: we also need those in order to receive
>  replies from the server.

You can use (GFP_ATOMIC & !__GFP_HIGH) to avoid draining emergency pools.

-
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/