All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Jan Kara <jack@suse.cz>, Corrado Zoccolo <czoccolo@gmail.com>,
	"Alex,Shi" <alex.shi@intel.com>,
	"Li, Shaohua" <shaohua.li@intel.com>,
	Vivek Goyal <vgoyal@redhat.com>, "tytso@mit.edu" <tytso@mit.edu>,
	"jaxboe@fusionio.com" <jaxboe@fusionio.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Chen, Tim C" <tim.c.chen@intel.com>
Subject: Re: [performance bug] kernel building regression on 64 LCPUs machine
Date: Fri, 4 Mar 2011 16:32:48 +0100	[thread overview]
Message-ID: <20110304153248.GC2649@quack.suse.cz> (raw)
In-Reply-To: <x49lj0x0zve.fsf@segfault.boston.devel.redhat.com>

  Hi Jeff,
On Wed 02-03-11 20:14:13, Jeff Moyer wrote:
> So, the results are in.  The test workload is an fs_mark process writing
> out 64k files and fsyncing each file after it's written.  Concurrently
> with this is a fio job running a buffered sequential reader (bsr).  Each
> data point is the average of 10 runs, after throwing out the first run.
> File system mount options are left at their defaults, which means that
> barriers are on.  The storage is an HP EVA, connected to the host via a
> single 4Gb FC path.
  Thanks a lot for testing! BTW: fs_mark runs in a single thread or do you
use more threads?

> ext3 looks marginally better with your patches.  We get better files/sec
> AND better throughput from the buffered reader.  For ext4, the results
> are less encouraging.  We see a drop in files/sec, and an increase in
> throughput for the sequential reader.  So, the fsync-ing is being
> starved a bit more than before.
> 
>         ||       ext3        ||       ext4        ||
>         || fs_mark | fio bsr || fs_mark | fio bsr ||
> --------++---------+---------++---------+---------||
> vanilla || 517.535 | 178187  || 408.547 | 277130  ||
> patched || 540.34  | 182312  || 342.813 | 294655  ||
> ====================================================
> %diff   ||  +4.4% |    +2.3% ||  -16.1% |  +6.3%  ||
Interesting. I'm surprised ext3 and ext4 results differ this much. I'm more
than happy with ext3 results since I just wanted to verify that fsync load
doesn't degrade too much with the improved logic preferring non-fsync load
more than we used to.

I'm not so happy with ext4 results. The difference between ext3 and ext4
might be that amount of data written by kjournald in ext3 is considerably
larger if it ends up pushing out data (because of data=ordered mode) as
well. With ext4, all data are written by filemap_fdatawrite() from fsync
because of delayed allocation. And thus maybe for ext4 WRITE_SYNC_PLUG
is hurting us with your fast storage and small amount of written data? With
WRITE_SYNC, data would be already on it's way to storage before we get to
wait for them...

Or it could be that we really send more data in WRITE mode rather than in
WRITE_SYNC mode with the patch on ext4 (that should be verifiable with
blktrace). But I wonder how that could happen...

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

  reply	other threads:[~2011-03-04 15:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19  1:55 [performance bug] kernel building regression on 64 LCPUs machine Alex,Shi
2011-01-19  2:03 ` Shaohua Li
2011-01-19 12:56   ` Jan Kara
2011-01-20  7:52     ` Alex,Shi
2011-01-20 15:16   ` Vivek Goyal
2011-01-21  7:17     ` Shaohua Li
2011-01-26  8:15     ` Shaohua Li
2011-02-12  9:21       ` Alex,Shi
2011-02-12 18:25         ` Corrado Zoccolo
2011-02-14  2:25           ` Alex,Shi
2011-02-15  1:10             ` Shaohua Li
2011-02-21 16:49               ` Jan Kara
2011-02-23  8:24                 ` Alex,Shi
2011-02-24 12:13                   ` Jan Kara
2011-02-25  0:44                     ` Alex Shi
2011-02-26 14:45                     ` Corrado Zoccolo
2011-03-01 19:56                       ` Jeff Moyer
2011-03-02  9:42                         ` Jan Kara
2011-03-02 16:13                           ` Jeff Moyer
2011-03-02 21:17                             ` Jan Kara
2011-03-02 21:20                               ` Jeff Moyer
2011-03-03  1:14                               ` Jeff Moyer
2011-03-04 15:32                                 ` Jan Kara [this message]
2011-03-04 15:40                                   ` Jeff Moyer
2011-03-04 15:50                                   ` Jeff Moyer
2011-03-04 18:27                                     ` Jeff Moyer
2011-03-22  7:38                                       ` Alex,Shi
2011-03-22 16:14                                         ` Jan Kara
2011-03-22 17:46                                           ` Jeff Moyer
2011-03-24  6:45                                             ` Alex,Shi
2011-03-28 19:48                                             ` Jan Kara
2011-01-19 14:32 ` Ted Ts'o
2011-01-20  2:12   ` Shaohua Li
2011-01-21  7:23 ` Corrado Zoccolo
2011-01-21  7:47   ` Alex,Shi
2011-01-21  7:52     ` Alex,Shi
2011-01-21  8:13       ` Corrado Zoccolo
2011-01-21  8:20   ` Shaohua Li

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=20110304153248.GC2649@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=alex.shi@intel.com \
    --cc=czoccolo@gmail.com \
    --cc=jaxboe@fusionio.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=tim.c.chen@intel.com \
    --cc=tytso@mit.edu \
    --cc=vgoyal@redhat.com \
    /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.