Re: [patch 1/2] fs: mnt_want_write speedup

[Al Viro]

On Thu, Apr 02, 2009 at 12:08:07PM -0700, Dave Hansen wrote:
> 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?

mnt_want_write() checks for superblock having gone readonly as well, and
we want to preserve that in some form.  OTOH, we probably want to move
that upstream from that place anyway.

BTW, mmap()/get page dirty/have filesystem forcibly go r-o on its own and
see how messy does it get is an useful regression test...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/