On Thu, 2009-04-02 at 19:43 +0100, Al Viro wrote: > On Thu, Apr 02, 2009 at 08:22:10PM +0200, Nick Piggin wrote: > > On Wed, Mar 18, 2009 at 12:13:43PM -0700, Dave Hansen wrote: > > > On Thu, 2009-03-12 at 05:13 +0100, Nick Piggin wrote: > > > > On Wed, Mar 11, 2009 at 03:11:17PM -0700, Dave Hansen wrote: > > > > > I'm feeling a bit better about these, although I am still honestly quite > > > > > afraid of the barriers. I also didn't like all the #ifdefs much, but > > > > > here's some help on that. > > > > > > > > FWIW, we have this in suse kernels because page fault performance was > > > > so bad compared with SLES10. mnt_want_write & co was I think the 2nd > > > > biggest offender for file backed mappings (after pvops). I think we're > > > > around parity again even with pvops. > > > > > > Page faults themselves? Which path was that from? > > > > Yes. file_update_time. > > FWIW, I'm not sure that this optimization is valid. We might eventually > want to go for "don't allow any new writers, remount r/o when existing > ones expire" functionality, so nested mnt_want_write() might eventually > be allowed to fail. That makes sense on a larger scale definitely. But I do wonder about file_update_time() specifically, especially since its mnt_want_write() is never persistent and it is always done under the cover of a FMODE_WRITE 'struct file'. Do we strictly even need the mnt_want/drop_write() pair in here at all right now? -- Dave -- 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
