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
