Date: Fri, 23 Dec 2005 16:17:11 +0100
From: Andrea Arcangeli <andrea@suse.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: nfs invalidates lose pte dirty bits
Message-ID: <20051223151711.GA9576@opteron.random>
References: <20051222175550.GT9576@opteron.random> <1135294250.3685.16.camel@lade.trondhjem.org> <20051223023603.GY9576@opteron.random> <1135327315.8167.11.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1135327315.8167.11.camel@lade.trondhjem.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1372
Lines: 28

On Fri, Dec 23, 2005 at 09:41:55AM +0100, Trond Myklebust wrote:
> On Fri, 2005-12-23 at 03:36 +0100, Andrea Arcangeli wrote:
> > On Thu, Dec 22, 2005 at 06:30:49PM -0500, Trond Myklebust wrote:
> > > See the latest git release where we introduce the nfs_sync_mapping()
> > > helper.
> > 
> > So you also still break completely with threaded programs, did you
> > consider that while fixing the most obvious problem? Isn't that a
> > problem too? What about my suggestion of invalidate_inode_clean_pages?
> 
> It is only a problem when doing mmap writes. In the case of ordinary

Yes, those changes are all about mmap writes.

> However if the user is doing mmap writes while the file is in the
> process of being modified on the server, then they are doing something
> wrong anyway. The small race between nfs_sync_mapping() and
> invalidate_inode_pages2() is the least of their problems.

I'm talking about spurious revalidates, I don't think the testcase I'm
dealing with is really needing an invalidate, it's a spurious one
(perhaps triggered by flock), but I'm lucky it's single threaded so
current fix will work for them.
-
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/