From: Larry Woodman on
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Heinz Diehl on
On 20.05.2010, Larry Woodman wrote:

> Increasing the dirty_ratio to 40% will regain the performance loss seen
> in several benchmarks. Whats everyone think about this???

These are tuneable via sysctl. What I have in my /etc/sysctl.conf is

vm.dirty_ratio = 4
vm.dirty_background_ratio = 2

This writes back the data more often and frequently, thus preventing the
system from long stalls.

Works at least for me. AMD Quadcore, 8 GB RAM.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Richard Kennedy on
On 20/05/10 13:29, Heinz Diehl wrote:
> On 20.05.2010, Larry Woodman wrote:
> lwoodman(a)redhat.com
>> Increasing the dirty_ratio to 40% will regain the performance loss seen
>> in several benchmarks. Whats everyone think about this???
>
> These are tuneable via sysctl. What I have in my /etc/sysctl.conf is
>
> vm.dirty_ratio = 4
> vm.dirty_background_ratio = 2
>
> This writes back the data more often and frequently, thus preventing the
> system from long stalls.
>
> Works at least for me. AMD Quadcore, 8 GB RAM.
>
get_dirty_limits uses a minimum vm_dirty_ratio of 5, so you can't set it
lower than that (unless you use vm_dirty_bytes).
But it's interesting that you find lowering the dirty_ratio helpful. Do
you have any benchmark results you can share?
regards
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Heinz Diehl on
On 20.05.2010, Richard Kennedy wrote:

> But it's interesting that you find lowering the dirty_ratio helpful. Do
> you have any benchmark results you can share?

No, unfortunately not. My machine is mainly designed to run squid,
and it suffered from very long stalls. After posting the problem, I was
advised to read about vm.dirty_ratio and vm.dirty_background_ratio, and
lower these. I tried several combinations, and with 4/2, the stalls
vanished completely.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on
Hi

CC to Nick and Jan

> 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???

In past, Jan Kara also claim the exactly same thing.

Subject: [LSF/VM TOPIC] Dynamic sizing of dirty_limit
Date: Wed, 24 Feb 2010 15:34:42 +0100

> (*) We ended up increasing dirty_limit in SLES 11 to 40% as it used to be
> with old kernels because customers running e.g. LDAP (using BerkelyDB
> heavily) were complaining about performance problems.

So, I'd prefer to restore the default rather than both Redhat and SUSE apply exactly
same distro specific patch. because we can easily imazine other users will face the same
issue in the future.

Acked-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com>

Nick, Jan, if the above is too old and your distro have been dropped the patch, please
correct me.

My motivation is, distro specific patches should keep minimum as far as possible.
It exactly help I and other MM developers handle MM bug report.

Thanks.


> ------------------------------------------------------------------------
>
> 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(a)kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a>



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/