From: Ted Ts'o <tytso@mit.edu>
To: Bill Fink <billfink@mindspring.com>
Cc: adilger@sun.com, linux-ext4@vger.kernel.org, bill.fink@nasa.gov
Subject: Re: [RFC PATCH] ext4: fix 50% disk write performance regression
Date: Mon, 30 Aug 2010 13:40:00 -0400 [thread overview]
Message-ID: <20100830174000.GA6647@thunk.org> (raw)
In-Reply-To: <20100829231126.8d8b2086.billfink@mindspring.com>
On Sun, Aug 29, 2010 at 11:11:26PM -0400, Bill Fink wrote:
> A 50% ext4 disk write performance regression was introduced
> in 2.6.32 and still exists in 2.6.35, although somewhat improved
> from 2.6.32. Read performance was not affected).
Thanks for reporting it. I'm going to have to take a closer look at
why this makes a difference. I'm going to guess though that what's
going on is that we're posting writes in such a way that they're no
longer aligned or ending at the end of a RAID5 stripe, causing a
read-modify-write pass. That would easily explain the write
performance regression.
The interesting thing is that we don't actually do anything in
ext4_da_writepages() to assure that we are making our writes are
appropriate aligned and sized. We do pay attention to make sure they
are alligned correctly in the allocator, but _not_ in the writepages
code. So the fact that apparently things were well aligned in 2.6.32
seems to be luck... (or maybe the writes are perfectly aligned in
2.6.32; they're just much worse with 2.6.35, and with explicit
attention paid to the RAID stripe size, we could do even better :-)
If you could run blktraces on 2.6.32, 2.6.35 stock, and 2.6.35 with
your patch, that would be really helpful to confirm my hypothesis. Is
that something that wouldn't be too much trouble?
Thanks, regards,
- Ted
next prev parent reply other threads:[~2010-08-30 17:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-30 3:11 [RFC PATCH] ext4: fix 50% disk write performance regression Bill Fink
2010-08-30 17:05 ` Eric Sandeen
2010-08-30 19:30 ` Bill Fink
2010-08-30 19:35 ` Eric Sandeen
2010-08-30 17:40 ` Ted Ts'o [this message]
2010-08-30 20:49 ` Bill Fink
2010-08-30 21:05 ` Eric Sandeen
[not found] ` <20100830194533.6d09c38b.bill@wizard.sci.gsfc.nasa.gov>
2010-08-30 23:53 ` Eric Sandeen
[not found] ` <20100830210541.8b248a14.billfink@mindspring.com>
[not found] ` <4C7C62E9.4090707@redhat.com>
2010-08-31 3:27 ` Bill Fink
2010-08-31 3:29 ` Eric Sandeen
2010-08-31 0:37 ` Ted Ts'o
2010-08-31 0:51 ` Justin Maggard
2010-08-31 1:44 ` Bill Fink
2010-08-31 1:14 ` Bill Fink
2010-08-31 3:43 ` [PATCH] " Eric Sandeen
2010-08-31 4:26 ` Eric Sandeen
2010-08-31 4:53 ` Bill Fink
2010-08-31 5:05 ` Eric Sandeen
2010-08-31 5:31 ` Bill Fink
2010-09-09 0:23 ` Daniel Taylor
2010-09-09 3:29 ` Eric Sandeen
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=20100830174000.GA6647@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=bill.fink@nasa.gov \
--cc=billfink@mindspring.com \
--cc=linux-ext4@vger.kernel.org \
/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.