From: Bill Fink <billfink@mindspring.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: tytso@mit.edu, adilger@sun.com, linux-ext4@vger.kernel.org,
bill.fink@nasa.gov
Subject: Re: [PATCH] ext4: fix 50% disk write performance regression
Date: Tue, 31 Aug 2010 01:31:08 -0400 [thread overview]
Message-ID: <20100831013108.2e4acb59.billfink@mindspring.com> (raw)
In-Reply-To: <4C7C8DAE.50902@redhat.com>
On Tue, 31 Aug 2010, Eric Sandeen wrote:
> Bill Fink wrote:
> > On Mon, 30 Aug 2010, Eric Sandeen wrote:
> >
> >> Can you give this a shot?
> >>
> >> The first hunk is, I think, the biggest problem. Even if
> >> we get the max number of pages we need, we keep scanning forward
> >> until "done" without doing any more actual, useful work.
> >>
> >> The 2nd hunk is an oddity, some places assign nr_to_write
> >> to LONG_MAX, and we get here and multiply -that- by 8... giving
> >> us "-8" for nr_to_write, that can't help things when we
> >> do later comparisons on that number...
> >>
> >> I also see us asking to find pages starting at "idx" and
> >> the first dirty page we find is well ahead of that,
> >> I'm not sure if that's indicative of a problem or not.
> >>
> >> Anyway, want to give this a shot, in place of the patch you sent,
> >> and see how it fares compared to stock and/or with your patch?
> >>
> >> It's build-and-sanity tested but not really performance tested here.
> >>
> >> Thanks,
> >> -Eric
> >
> > Great! It looks like that does the trick.
> >
> > 2.6.35 + your patch:
> >
> > i7test7% dd if=/dev/zero of=/i7raid/bill/testfile1 bs=1M count=32768
> > 32768+0 records in
> > 32768+0 records out
> > 34359738368 bytes (34 GB) copied, 50.6702 s, 678 MB/s
> >
> > That's the same performance as with my patch, and pretty darn
> > close to the original 2.6.31 performance.
>
> hah, that's good esp. considering my followup email that found
> what I think is a problem with my patch. ;)
>
> What happens if you change:
>
> if (!range_cyclic && range_whole && wbc->nr_to_write != LONG_MAX)
> desired_nr_to_write = wbc->nr_to_write * 8;
> else
> desired_nr_to_write = ext4_num_dirty_pages(inode, index,
>
> to:
>
> if (!range_cyclic && range_whole) {
> if (wbc->nr_to_write != LONG_MAX)
> desired_nr_to_write = wbc->nr_to_write * 8;
> else
> desired_nr_to_write = wbc->nr_to_write;
> } else
> desired_nr_to_write = ext4_num_dirty_pages(inode, index,
>
> and see how that fares? I think that makes a little more sense, if we
> got there with LONG_MAX that means "write everything" and there's no need
> to bump it up or to go counting pages. It may not make any real difference.
That's also fine.
-Bill
> But I'm seeing really weird behavior in writeback, it starts out nicely
> writing 32768 pages at a time, and then goes all wonky, revisiting pages
> it's already done and doing IO in little chunks. This is going to take
> some staring I think.
>
> -Eric
next prev parent reply other threads:[~2010-08-31 5:31 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
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 [this message]
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=20100831013108.2e4acb59.billfink@mindspring.com \
--to=billfink@mindspring.com \
--cc=adilger@sun.com \
--cc=bill.fink@nasa.gov \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--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.