All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Josef Bacik <josef@redhat.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	"Ted Ts'o" <tytso@mit.edu>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] ext4: turn on i_version updates by default
Date: Tue, 15 May 2012 09:28:57 -0400	[thread overview]
Message-ID: <20120515132857.GA1907@localhost.localdomain> (raw)
In-Reply-To: <60F0B94D-FDB9-4401-B0EA-1A1C6DE4086F@dilger.ca>

On Mon, May 14, 2012 at 03:27:47PM -0600, Andreas Dilger wrote:
> On 2012-05-14, at 1:05 PM, Josef Bacik wrote:
> > On Mon, May 14, 2012 at 02:54:00PM -0400, J. Bruce Fields wrote:
> >> I don't think they're worried about the inode_inc_iversion() calls
> >> themselves, but the behavior of file_update_time():
> >> 
> >>        if (!timespec_equal(&inode->i_mtime, &now))
> >>                sync_it = S_MTIME;
> >> 
> >>        if (!timespec_equal(&inode->i_ctime, &now))
> >>                sync_it |= S_CTIME;
> >> 
> >>        if (IS_I_VERSION(inode))
> >>                sync_it |= S_VERSION;
> >> 
> >>        if (!sync_it)
> >>                return;
> >> 	...
> >> 	mark_inode_dirty_sync(inode);
> >> 
> >> So now mark_inode_dirty_sync() is called on every update, instead of
> >> merely on every update that sees a time change (so at most once a
> >> jiffy).
> >> 
> >> So mark_inode_dirty_sync (and hence ->dirty_inode = ext4_dirty_inode)
> >> may get called more often if you're writing very frequently.
> >> 
> >> I'm a bit surprised that's expected to add significant overhead to the
> >> write.
> > 
> > It shouldn't, let's be honest, most systems aren't going to have such
> > a coarse jiffie counter that they'll be able to get away with doing
> > 2 calls to write() or ->page_mkwrite() in the same jiffie and skip the
> > update to mtime/ctime anyway.  If they do they are damned lucky, and
> > again the amount of overhead added even if they are should be
> > negligible since 99% of us all incur the overhead from having
> > to update mtime/ctime anyway.  Thanks,
> 
> Seriously?  The whole reason the above checks for timespec_equal()
> are there is to avoid calling mark_inode_dirty_sync() thousands of
> times per second.  If doing write() calls in the same jiffie were
> so rare as you suggest then I don't think such an optimization
> would ever have appeared in the first place.
> 

So here is the commit log

commit ce06e0b21d6732a2bab10a585a3ec6909499be28
Author: Andi Kleen <andi@firstfloor.org>
Date:   Fri Sep 18 13:05:48 2009 -0700

    vfs: optimize touch_time() too
    
    Do a similar optimization as earlier for touch_atime.  Getting the lock in
    mnt_get_write is relatively costly, so try all avenues to avoid it first.
    
    This patch is careful to still only update inode fields inside the lock
    region.
    
    This didn't show up in benchmarks, but it's easy enough to do.

Notice that last bit?  I'm sure maybe at some point in the future we'll be able
to see the overhead, but right now I highly doubt we can, and if we can I'd like
to see benchmarks before blanket dismissing a feature that would be super
helpful for people exporting nfs volumes.  Thanks,

Josef

  reply	other threads:[~2012-05-15 13:28 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14 14:06 [PATCH] ext4: turn on i_version updates by default J. Bruce Fields
     [not found] ` <20120514140618.GA29902-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-05-14 15:02   ` Andreas Dilger
2012-05-14 15:02     ` Andreas Dilger
     [not found]     ` <9124E59E-2479-4C32-A528-3237B48DEC01-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>
2012-05-14 15:23       ` J. Bruce Fields
2012-05-14 15:23         ` J. Bruce Fields
     [not found]         ` <20120514152334.GB29902-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-05-14 17:27           ` Andreas Dilger
2012-05-14 17:27             ` Andreas Dilger
     [not found]             ` <14B38D68-FAE4-444A-BCD9-7EBF7E1BBFE1-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>
2012-05-14 17:58               ` Ted Ts'o
2012-05-14 17:58                 ` Ted Ts'o
     [not found]                 ` <20120514175822.GC1439-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2012-05-14 18:33                   ` Josef Bacik
2012-05-14 18:33                     ` Josef Bacik
     [not found]                     ` <20120514183316.GA1894-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2012-05-14 18:48                       ` Jeff Layton
2012-05-14 18:48                         ` Jeff Layton
     [not found]                         ` <20120514144802.679551fa-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2012-05-14 18:51                           ` Josef Bacik
2012-05-14 18:51                             ` Josef Bacik
2012-05-14 18:54                       ` J. Bruce Fields
2012-05-14 18:54                         ` J. Bruce Fields
2012-05-14 19:05                         ` Josef Bacik
     [not found]                           ` <20120514190500.GC1894-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2012-05-14 21:27                             ` Andreas Dilger
2012-05-14 21:27                               ` Andreas Dilger
2012-05-15 13:28                               ` Josef Bacik [this message]
2012-05-15 17:59                                 ` Marco Stornelli
2012-05-15 19:18                                   ` J. Bruce Fields
2012-05-15 17:33             ` J. Bruce Fields
2012-05-15 18:50               ` djwong
2012-05-14 23:08     ` Myklebust, Trond
2012-05-14 23:08       ` Myklebust, Trond
     [not found]       ` <1337036918.2522.32.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
2012-05-14 23:33         ` Andreas Dilger
2012-05-14 23:33           ` Andreas Dilger
2012-05-14 23:54           ` J. Bruce Fields
     [not found]             ` <20120514235432.GA3199-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-05-15 10:30               ` Jan Kara
2012-05-15 10:30                 ` Jan Kara
2012-05-15 12:35                 ` J. Bruce Fields
2012-05-15 14:43                   ` Jan Kara
2012-05-15  0:13           ` Myklebust, Trond
2012-05-15  0:13             ` Myklebust, Trond

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120515132857.GA1907@localhost.localdomain \
    --to=josef@redhat.com \
    --cc=adilger@dilger.ca \
    --cc=bfields@fieldses.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.