From: Chris Mason <chris.mason@oracle.com>
To: Jan Kara <jack@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
David Miller <davem@davemloft.net>,
akpm@linux-foundation.org, peterz@infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
npiggin@suse.de
Subject: Re: Increase dirty_ratio and dirty_background_ratio?
Date: Fri, 09 Jan 2009 14:07:22 -0500 [thread overview]
Message-ID: <1231528042.5998.13.camel@think.oraclecorp.com> (raw)
In-Reply-To: <20090109180241.GA15023@duck.suse.cz>
On Fri, 2009-01-09 at 19:02 +0100, Jan Kara wrote:
> What we observe in the seekwatcher graphs is, that there are three
> processes writing back the single database file in parallel (2 pdflush
> threads because the machine has 2 CPUs, and the database process itself
> because of dirty throttling). Each of the processes is writing back the
> file at a different offset and so they together create even more random IO
> (I'm attaching the graph and can provide blocktrace data if someone is
> interested). If there was just one process doing the writeback, we'd be
> writing back those data considerably faster...
I spent some time trying similar things for btrfs, and went as far as
making my own writeback thread and changing pdflush and throttled writes
to wait on it. It was a great hack, but in the end I found the real
problem was the way write_cache_pages is advancing the page_index.
You probably remember the related ext4 discussion, and you could try my
simple patch in this workload to see if it helps ext3.
http://lkml.org/lkml/2008/10/1/278
Ext3 may need similar tricks.
-chris
WARNING: multiple messages have this Message-ID (diff)
From: Chris Mason <chris.mason@oracle.com>
To: Jan Kara <jack@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
David Miller <davem@davemloft.net>,
akpm@linux-foundation.org, peterz@infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
npiggin@suse.de
Subject: Re: Increase dirty_ratio and dirty_background_ratio?
Date: Fri, 09 Jan 2009 14:07:22 -0500 [thread overview]
Message-ID: <1231528042.5998.13.camel@think.oraclecorp.com> (raw)
In-Reply-To: <20090109180241.GA15023@duck.suse.cz>
On Fri, 2009-01-09 at 19:02 +0100, Jan Kara wrote:
> What we observe in the seekwatcher graphs is, that there are three
> processes writing back the single database file in parallel (2 pdflush
> threads because the machine has 2 CPUs, and the database process itself
> because of dirty throttling). Each of the processes is writing back the
> file at a different offset and so they together create even more random IO
> (I'm attaching the graph and can provide blocktrace data if someone is
> interested). If there was just one process doing the writeback, we'd be
> writing back those data considerably faster...
I spent some time trying similar things for btrfs, and went as far as
making my own writeback thread and changing pdflush and throttled writes
to wait on it. It was a great hack, but in the end I found the real
problem was the way write_cache_pages is advancing the page_index.
You probably remember the related ext4 discussion, and you could try my
simple patch in this workload to see if it helps ext3.
http://lkml.org/lkml/2008/10/1/278
Ext3 may need similar tricks.
-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-01-09 19:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 15:45 Increase dirty_ratio and dirty_background_ratio? Jan Kara
2009-01-07 16:25 ` Peter Zijlstra
2009-01-07 16:25 ` Peter Zijlstra
2009-01-07 16:39 ` Linus Torvalds
2009-01-07 16:39 ` Linus Torvalds
2009-01-07 20:51 ` David Miller
2009-01-07 20:51 ` David Miller
2009-01-08 11:02 ` Andrew Morton
2009-01-08 11:02 ` Andrew Morton
2009-01-08 16:24 ` David Miller
2009-01-08 16:24 ` David Miller
2009-01-08 16:48 ` Linus Torvalds
2009-01-08 16:48 ` Linus Torvalds
2009-01-08 16:55 ` Chris Mason
2009-01-08 16:55 ` Chris Mason
2009-01-08 17:05 ` Linus Torvalds
2009-01-08 17:05 ` Linus Torvalds
2009-01-08 19:57 ` Jan Kara
2009-01-08 19:57 ` Jan Kara
2009-01-08 20:01 ` David Miller
2009-01-08 20:01 ` David Miller
2009-01-09 18:02 ` Jan Kara
2009-01-09 19:00 ` Andrew Morton
2009-01-09 19:00 ` Andrew Morton
2009-01-09 19:07 ` Chris Mason [this message]
2009-01-09 19:07 ` Chris Mason
2009-01-09 22:31 ` david
2009-01-09 21:34 ` Peter Zijlstra
2009-01-09 21:34 ` Peter Zijlstra
2009-01-14 3:29 ` Nick Piggin
2009-01-14 3:29 ` Nick Piggin
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=1231528042.5998.13.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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.