From: Chris Mason <chris.mason@oracle.com>
To: Richard Kennedy <richard@rsk.demon.co.uk>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] mm: stop balance_dirty_pages doing too much work
Date: Fri, 7 Aug 2009 11:22:11 -0400 [thread overview]
Message-ID: <20090807152210.GH17129@think> (raw)
In-Reply-To: <1249655761.2719.11.camel@localhost.localdomain>
On Fri, Aug 07, 2009 at 03:36:01PM +0100, Richard Kennedy wrote:
> On Fri, 2009-08-07 at 14:20 +0200, Peter Zijlstra wrote:
> > On Wed, 2009-06-24 at 11:38 +0100, Richard Kennedy wrote:
> ...
> > OK, so Chris ran into this bit yesterday, complaining that he'd only get
> > very few write requests and couldn't saturate his IO channel.
> >
> > Now, since writing out everything once there's something to do sucks for
> > Richard, but only writing out stuff when we're over the limit sucks for
> > Chris (since we can only be over the limit a little), the best thing
> > would be to only write out when we're over the background limit. Since
> > that is the low watermark we use for throttling it makes sense that we
> > try to write out when above that.
> >
> > However, since there's a lack of bdi_background_thresh, and I don't
> > think introducing one just for this is really justified. How about the
> > below?
> >
> > Chris how did this work for you? Richard, does this make things suck for
> > you again?
> >
> > ---
> > mm/page-writeback.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> > index 81627eb..92f42d6 100644
> > --- a/mm/page-writeback.c
> > +++ b/mm/page-writeback.c
> > @@ -545,7 +545,7 @@ static void balance_dirty_pages(struct address_space *mapping)
> > * threshold otherwise wait until the disk writes catch
> > * up.
> > */
> > - if (bdi_nr_reclaimable > bdi_thresh) {
> > + if (bdi_nr_reclaimable > bdi_thresh/2) {
My patch had two extra spaces ;)
> > writeback_inodes(&wbc);
> > pages_written += write_chunk - wbc.nr_to_write;
> > get_dirty_limits(&background_thresh, &dirty_thresh,
> >
> >
> I'll run some tests and let you know :)
>
> But what if someone has changed the vm settings?
> Maybe something like
> (bdi_thresh * dirty_background_ratio / dirty_ratio)
> might be better ?
>
> Chris, what sort of workload are you having problems with?
So, buffered writeback in general has a bunch of interesting features
right now, and to be honest I'm having a hard time untangling all of it.
It doesn't help that each of our filesystems is reacting differently.
Btrfs and XFS both use helper threads to process IO completion. This
means that we tend to collect more writeback pages than the other
filesystems do.
The end result of this is that O_DIRECT is dramatically faster than
buffered on every streaming write workload I've tried. I'm still trying
to sort out exactly where buffered IO is going wrong.
-chris
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-08-07 15:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-24 10:38 Richard Kennedy
2009-06-24 22:27 ` Andrew Morton
2009-06-25 5:13 ` Jens Axboe
2009-06-25 8:00 ` Peter Zijlstra
2009-06-25 9:10 ` Jens Axboe
2009-06-25 9:26 ` Jens Axboe
2009-06-25 12:33 ` Al Boldi
2009-06-25 12:43 ` Jens Axboe
2009-06-25 13:46 ` Al Boldi
2009-06-25 14:44 ` Jens Axboe
2009-06-25 17:10 ` Al Boldi
2009-06-26 5:02 ` Jens Axboe
2009-06-26 11:37 ` Al Boldi
2009-06-26 12:35 ` Jens Axboe
2009-06-26 9:15 ` Richard Kennedy
2009-06-26 9:20 ` Jens Axboe
2009-08-07 12:20 ` Peter Zijlstra
2009-08-07 14:36 ` Richard Kennedy
2009-08-07 14:38 ` Peter Zijlstra
2009-08-07 15:22 ` Chris Mason [this message]
2009-08-07 16:09 ` Richard Kennedy
2009-08-07 21:02 ` Chris Mason
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=20090807152210.GH17129@think \
--to=chris.mason@oracle.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=richard@rsk.demon.co.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