linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>, Curt Wohlgemuth <curtw@google.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	fengguang.wu@intel.com
Subject: Re: [PATCH] writeback: Don't wait for completion in writeback_inodes_sb_nr
Date: Thu, 21 Jul 2011 20:35:23 +0200	[thread overview]
Message-ID: <20110721183523.GA4509@quack.suse.cz> (raw)
In-Reply-To: <20110719165639.GC11540@infradead.org>

On Tue 19-07-11 12:56:39, Christoph Hellwig wrote:
> On Fri, Jul 15, 2011 at 01:08:54AM +0200, Jan Kara wrote:
> >   Actually, it's the other way around writeback_inodes_sb() is superfluous
> > because of wakeup_flusher_threads(). So something like attached patch could
> > improve sync times (especially in presence of other IO). So far I have only
> > checked that sync times look reasonable with it but didn't really compare
> > them with original kernel...
> 
> This changes the order in which ->quota_sync is called relatively to
> other operations, see my other mail about it.  Also the code gets really
> confusing at this point, I think you're better of stopping to try to
> shared code between syncfs, umount & co and sys_sync with these bits.
  Good point. I'll stop sharing the code for these two cases.

> You're also skipping the ->sync_fs and quotasync calls the first round.
  Well, kind of. Since writeback is running asynchronously, we have no way
to call ->sync_fs(sb, 0) just after async inode writeback is done (and it
doesn't really make sense to call it before that moment). So we call
synchronous inode writeback first and only then ->sync_fs().

> I know for XFS sync_fs without wait is already mostly a no-op, but we'll
> need to benchmark and document this change, and apply it to the non-sync
> caller as well.
  I already have some numbers:
I've checked pure sync overhead by
  sync; time for (( i = 0; i < 100; i++ )); do sync; done
the results of 5 runs are:
  avg 1.130400s, stddev 0.027369 (unpatched kernel)
  avg 1.073200s, stddev 0.040848 (patched kernel)
so as expected slightly better for patched kernel.

And test with 20000 4k files in 100 directories on xfs:
  avg 155.995600s, stddev 1.879084 (unpatched kernel)
  avg 155.942200s, stddev 1.843881 (patched kernel)
so no real difference.

The same test with ext3:
  avg 154.597200s, stddev 1.556965 (unpatched kernel)
  avg 153.109800s, stddev 1.339094 (patched kernel)
again almost no difference.

  Where would you like to document the change?

								Honza

-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2011-07-21 18:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-28 23:43 [PATCH] writeback: Don't wait for completion in writeback_inodes_sb_nr Curt Wohlgemuth
2011-06-29  0:54 ` Dave Chinner
2011-06-29  1:56   ` Curt Wohlgemuth
2011-06-29  8:11     ` Christoph Hellwig
2011-06-29 16:57       ` Jan Kara
2011-06-29 17:55         ` Christoph Hellwig
2011-06-29 19:15           ` Jan Kara
2011-06-29 20:12             ` Christoph Hellwig
2011-06-30 12:15               ` Jan Kara
2011-06-30 12:37                 ` Christoph Hellwig
2011-07-01 22:55             ` Curt Wohlgemuth
2011-07-02 11:32               ` Christoph Hellwig
2011-07-11 17:00               ` Jan Kara
2011-07-11 17:11                 ` Curt Wohlgemuth
2011-07-11 19:48                   ` Jan Kara
2011-07-11 19:51                     ` Curt Wohlgemuth
2011-07-11 20:11                     ` Christoph Hellwig
2011-07-12 10:34                       ` Jan Kara
2011-07-12 10:41                         ` Christoph Hellwig
2011-07-12 22:37                           ` Jan Kara
2011-07-14 16:29                             ` Curt Wohlgemuth
2011-07-14 23:08                               ` Jan Kara
2011-07-19 16:56                                 ` Christoph Hellwig
2011-07-21 18:35                                   ` Jan Kara [this message]
2011-07-22 15:16                                     ` Christoph Hellwig
2011-07-19 16:53                               ` Christoph Hellwig
2011-07-19 16:51                             ` Christoph Hellwig
2011-07-20 22:00                               ` Jan Kara
2011-07-22 15:11                                 ` Christoph Hellwig
2011-06-29 17:26       ` Curt Wohlgemuth
2011-06-29 18:00         ` Christoph Hellwig
2011-06-29 21:30           ` Curt Wohlgemuth
2011-07-19 15:54             ` Christoph Hellwig
2011-06-29  6:42   ` Christoph Hellwig

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=20110721183523.GA4509@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=curtw@google.com \
    --cc=fengguang.wu@intel.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).