Return-Path: Received: from fieldses.org ([174.143.236.118]:50642 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805Ab0HRTcz (ORCPT ); Wed, 18 Aug 2010 15:32:55 -0400 Date: Wed, 18 Aug 2010 15:30:43 -0400 From: "J. Bruce Fields" To: Andi Kleen Cc: Neil Brown , Alan Cox , "Patrick J. LoPresti" , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel Subject: Re: Proposal: Use hi-res clock for file timestamps Message-ID: <20100818193043.GG13050@fieldses.org> References: <20100817174134.GA23176@fieldses.org> <20100817182920.GD18161@basil.fritz.box> <20100817190447.GA28049@fieldses.org> <20100817203941.729830b7@lxorguk.ukuu.org.uk> <20100817192937.GD26609@fieldses.org> <20100818155359.66b9ddb6@notabene> <20100818175040.GA6567@basil.fritz.box> <20100818185456.GD13050@fieldses.org> <20100818192508.GC6567@basil.fritz.box> Content-Type: text/plain; charset=us-ascii In-Reply-To: <20100818192508.GC6567@basil.fritz.box> Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Wed, Aug 18, 2010 at 09:25:08PM +0200, Andi Kleen wrote: > On Wed, Aug 18, 2010 at 02:54:56PM -0400, J. Bruce Fields wrote: > > On Wed, Aug 18, 2010 at 07:50:40PM +0200, Andi Kleen wrote: > > > > - nfsd updates it whenever it reads an mtime out of an inode that matches > > > > current_fs_time to the granularity of 1/HZ. > > > > > > That means you have a very very hot cache line on a larger system > > > if there are a lot of mtime changes. Probably a bad idea. > > > > Only if those mtime changes are also followed immediately by nfsd reads > > of the mtime. > > If multiple writers are changing the same location in quick succession > you have a hot cache line that gets bounced around. It doesn't need reads, > although reads make it even worse. OK, at this point one of us is confused, and I'm not sure which. Is the "same location" that you're referring to the current_nfsd_time? Neil's suggestion is to only modify current_nfsd_time on nfsd getattr, *not* on the write operation that modifies the file data. Or are you talking about something else? > There's a lot of effort currently to make the VFS more parallel > and less synchronized and it would be bad again to regress here again. Understood. --b.