Re: Proposal: Use hi-res clock for file timestamps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux