From: Christoph Hellwig <hch@infradead.org>
To: Larry Woodman <lwoodman@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>
Subject: Re: RFC: dirty_ratio back to 40%
Date: Tue, 8 Jun 2010 14:49:14 -0400 [thread overview]
Message-ID: <20100608184913.GA12154@infradead.org> (raw)
In-Reply-To: <4BF51B0A.1050901@redhat.com>
Did this patch get merged somewhere?
On Thu, May 20, 2010 at 07:20:42AM -0400, Larry Woodman wrote:
> We've seen multiple performance regressions linked to the lower(20%)
> dirty_ratio. When performing enough IO to overwhelm the background
> flush daemons the percent of dirty pagecache memory quickly climbs
> to the new/lower dirty_ratio value of 20%. At that point all
> writing processes are forced to stop and write dirty pagecache pages
> back to disk. This causes performance regressions in several
> benchmarks as well as causing
> a noticeable overall sluggishness. We all know that the dirty_ratio is
> an integrity vs performance trade-off but the file system journaling
> will cover any devastating effects in the event of a system crash.
>
> Increasing the dirty_ratio to 40% will regain the performance loss seen
> in several benchmarks. Whats everyone think about this???
>
>
>
>
>
> ------------------------------------------------------------------------
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index ef27e73..645a462 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -78,7 +78,7 @@ int vm_highmem_is_dirtyable;
> /*
> * The generator of dirty data starts writeback at this percentage
> */
> -int vm_dirty_ratio = 20;
> +int vm_dirty_ratio = 40;
>
> /*
> * vm_dirty_bytes starts at 0 (disabled) so that it is a function of
>
> --
> 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>
---end quoted text---
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Larry Woodman <lwoodman@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>
Subject: Re: RFC: dirty_ratio back to 40%
Date: Tue, 8 Jun 2010 14:49:14 -0400 [thread overview]
Message-ID: <20100608184913.GA12154@infradead.org> (raw)
In-Reply-To: <4BF51B0A.1050901@redhat.com>
Did this patch get merged somewhere?
On Thu, May 20, 2010 at 07:20:42AM -0400, Larry Woodman wrote:
> We've seen multiple performance regressions linked to the lower(20%)
> dirty_ratio. When performing enough IO to overwhelm the background
> flush daemons the percent of dirty pagecache memory quickly climbs
> to the new/lower dirty_ratio value of 20%. At that point all
> writing processes are forced to stop and write dirty pagecache pages
> back to disk. This causes performance regressions in several
> benchmarks as well as causing
> a noticeable overall sluggishness. We all know that the dirty_ratio is
> an integrity vs performance trade-off but the file system journaling
> will cover any devastating effects in the event of a system crash.
>
> Increasing the dirty_ratio to 40% will regain the performance loss seen
> in several benchmarks. Whats everyone think about this???
>
>
>
>
>
> ------------------------------------------------------------------------
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index ef27e73..645a462 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -78,7 +78,7 @@ int vm_highmem_is_dirtyable;
> /*
> * The generator of dirty data starts writeback at this percentage
> */
> -int vm_dirty_ratio = 20;
> +int vm_dirty_ratio = 40;
>
> /*
> * vm_dirty_bytes starts at 0 (disabled) so that it is a function of
>
> --
> 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>
---end quoted text---
--
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:[~2010-06-08 18:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-20 11:20 RFC: dirty_ratio back to 40% Larry Woodman
2010-05-20 11:20 ` Larry Woodman
2010-05-20 12:29 ` Heinz Diehl
2010-05-20 12:29 ` Heinz Diehl
2010-05-20 13:47 ` Richard Kennedy
2010-05-20 13:47 ` Richard Kennedy
2010-05-20 17:12 ` Heinz Diehl
2010-05-20 23:48 ` KOSAKI Motohiro
2010-05-20 23:48 ` KOSAKI Motohiro
2010-05-21 0:48 ` Zan Lynx
2010-05-21 0:48 ` Zan Lynx
2010-05-21 1:11 ` KOSAKI Motohiro
2010-05-21 1:11 ` KOSAKI Motohiro
2010-05-21 16:00 ` Jan Kara
2010-05-21 16:00 ` Jan Kara
2010-05-24 19:50 ` Ric Wheeler
2010-05-24 19:50 ` Ric Wheeler
2010-05-21 15:50 ` Jan Kara
2010-05-21 15:50 ` Jan Kara
2010-05-21 6:18 ` David Miller
2010-05-21 6:18 ` David Miller
2010-06-08 18:49 ` Christoph Hellwig [this message]
2010-06-08 18:49 ` Christoph Hellwig
2010-06-08 19:01 ` Larry Woodman
2010-06-08 19:01 ` Larry Woodman
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=20100608184913.GA12154@infradead.org \
--to=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwoodman@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.