* iozone regression with 2.6.29-rc6
@ 2009-02-27 9:13 Lin Ming
2009-02-27 9:49 ` Peter Zijlstra
0 siblings, 1 reply; 6+ messages in thread
From: Lin Ming @ 2009-02-27 9:13 UTC (permalink / raw)
To: npiggin, Peter Zijlstra; +Cc: linux-kernel, Zhang, Yanmin
bisect locates below commits,
commit 1cf6e7d83bf334cc5916137862c920a97aabc018
Author: Nick Piggin <npiggin@suse.de>
Date: Wed Feb 18 14:48:18 2009 -0800
mm: task dirty accounting fix
YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
Additionally, there is some inconsistency about when task_dirty_inc is
called. It is used for dirty balancing, however it even gets called for
__set_page_dirty_no_writeback.
So rather than increment it in a set_page_dirty wrapper, move it down to
exactly where the dirty page accounting stats are incremented.
Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
below data in parenthesis is the result after above commit reverted, for example,
-10% (+2%) means,
iozone has ~10% regression with 2.6.29-rc6 compared with 2.6.29-rc5.
and
iozone has ~2% improvement with 2.6.29-rc6-revert-1cf6e7d compared with 2.6.29-rc5.
4P dual-core HT 2P qual-core 2P qual-core HT
tulsa stockley Nehalem
--------------------------------------------------------
iozone-rewrite -10% (+2%) -8% (0%) -10% (-7%)
iozone-rand-write -50% (0%) -20% (+10%)
iozone-read -13% (0%)
iozone-write -28% (-1%)
iozone-reread -5% (-1%)
iozone-mmap-read -7% (+2%)
iozone-mmap-reread -7% (+2%)
iozone-mmap-rand-read -7% (+3%)
iozone-mmap-rand-write -5% (0%)
Lin Ming
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iozone regression with 2.6.29-rc6
2009-02-27 9:13 iozone regression with 2.6.29-rc6 Lin Ming
@ 2009-02-27 9:49 ` Peter Zijlstra
2009-02-27 11:55 ` Nick Piggin
2009-03-02 2:19 ` Lin Ming
0 siblings, 2 replies; 6+ messages in thread
From: Peter Zijlstra @ 2009-02-27 9:49 UTC (permalink / raw)
To: Lin Ming; +Cc: npiggin, linux-kernel, Zhang, Yanmin
On Fri, 2009-02-27 at 17:13 +0800, Lin Ming wrote:
> bisect locates below commits,
>
> commit 1cf6e7d83bf334cc5916137862c920a97aabc018
> Author: Nick Piggin <npiggin@suse.de>
> Date: Wed Feb 18 14:48:18 2009 -0800
>
> mm: task dirty accounting fix
>
> YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
> cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
>
> Additionally, there is some inconsistency about when task_dirty_inc is
> called. It is used for dirty balancing, however it even gets called for
> __set_page_dirty_no_writeback.
>
> So rather than increment it in a set_page_dirty wrapper, move it down to
> exactly where the dirty page accounting stats are incremented.
>
> Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
>
> below data in parenthesis is the result after above commit reverted, for example,
> -10% (+2%) means,
> iozone has ~10% regression with 2.6.29-rc6 compared with 2.6.29-rc5.
> and
> iozone has ~2% improvement with 2.6.29-rc6-revert-1cf6e7d compared with 2.6.29-rc5.
>
>
> 4P dual-core HT 2P qual-core 2P qual-core HT
> tulsa stockley Nehalem
> --------------------------------------------------------
> iozone-rewrite -10% (+2%) -8% (0%) -10% (-7%)
> iozone-rand-write -50% (0%) -20% (+10%)
> iozone-read -13% (0%)
> iozone-write -28% (-1%)
> iozone-reread -5% (-1%)
> iozone-mmap-read -7% (+2%)
> iozone-mmap-reread -7% (+2%)
> iozone-mmap-rand-read -7% (+3%)
> iozone-mmap-rand-write -5% (0%)
Ugh, that's unexpected..
So 'better' accounting leads to worse performance, which would indicate
we throttle more.
I take it you machine has gobs of memory.
Does something like the below help any?
---
Subject: mm: bdi: tweak task dirty penalty
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri Feb 27 10:41:22 CET 2009
Penalizing heavy dirtiers with 1/8-th the total dirty limit might be rather
excessive on large memory machines. Use sqrt to scale it sub-linearly.
Update the comment while we're there.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
mm/page-writeback.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c
+++ linux-2.6/mm/page-writeback.c
@@ -293,17 +293,21 @@ static inline void task_dirties_fraction
}
/*
- * scale the dirty limit
+ * Task specific dirty limit:
*
- * task specific dirty limit:
+ * dirty -= 8 * sqrt(dirty) * p_{t}
*
- * dirty -= (dirty/8) * p_{t}
+ * Penalize tasks that dirty a lot of pages by lowering their dirty limit. This
+ * avoids infrequent dirtiers from getting stuck in this other guys dirty
+ * pages.
+ *
+ * Use a sub-linear function to scale the penalty, we only need a little room.
*/
static void task_dirty_limit(struct task_struct *tsk, long *pdirty)
{
long numerator, denominator;
long dirty = *pdirty;
- u64 inv = dirty >> 3;
+ u64 inv = 8*int_sqrt(dirty);
task_dirties_fraction(tsk, &numerator, &denominator);
inv *= numerator;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iozone regression with 2.6.29-rc6
2009-02-27 9:49 ` Peter Zijlstra
@ 2009-02-27 11:55 ` Nick Piggin
2009-03-02 2:19 ` Lin Ming
1 sibling, 0 replies; 6+ messages in thread
From: Nick Piggin @ 2009-02-27 11:55 UTC (permalink / raw)
To: Peter Zijlstra, Linus Torvalds, Andrew Morton
Cc: Lin Ming, linux-kernel, Zhang, Yanmin
On Fri, Feb 27, 2009 at 10:49:14AM +0100, Peter Zijlstra wrote:
> On Fri, 2009-02-27 at 17:13 +0800, Lin Ming wrote:
> > bisect locates below commits,
> >
> > commit 1cf6e7d83bf334cc5916137862c920a97aabc018
> > Author: Nick Piggin <npiggin@suse.de>
> > Date: Wed Feb 18 14:48:18 2009 -0800
> >
> > mm: task dirty accounting fix
> >
> > YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
> > cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
> >
> > Additionally, there is some inconsistency about when task_dirty_inc is
> > called. It is used for dirty balancing, however it even gets called for
> > __set_page_dirty_no_writeback.
> >
> > So rather than increment it in a set_page_dirty wrapper, move it down to
> > exactly where the dirty page accounting stats are incremented.
> >
> > Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
> > Signed-off-by: Nick Piggin <npiggin@suse.de>
> > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> >
> >
> > below data in parenthesis is the result after above commit reverted, for example,
> > -10% (+2%) means,
> > iozone has ~10% regression with 2.6.29-rc6 compared with 2.6.29-rc5.
> > and
> > iozone has ~2% improvement with 2.6.29-rc6-revert-1cf6e7d compared with 2.6.29-rc5.
> >
> >
> > 4P dual-core HT 2P qual-core 2P qual-core HT
> > tulsa stockley Nehalem
> > --------------------------------------------------------
> > iozone-rewrite -10% (+2%) -8% (0%) -10% (-7%)
> > iozone-rand-write -50% (0%) -20% (+10%)
> > iozone-read -13% (0%)
> > iozone-write -28% (-1%)
> > iozone-reread -5% (-1%)
> > iozone-mmap-read -7% (+2%)
> > iozone-mmap-reread -7% (+2%)
> > iozone-mmap-rand-read -7% (+3%)
> > iozone-mmap-rand-write -5% (0%)
>
> Ugh, that's unexpected..
>
> So 'better' accounting leads to worse performance, which would indicate
> we throttle more.
>
> I take it you machine has gobs of memory.
>
> Does something like the below help any?
Shall we revert this for 2.6.29, then? And try to improve it in the next
cycle? Are we looking at a several more weeks before 2.6.29, or do we
prefer not to try tweaking heuristics at this point?
> ---
> Subject: mm: bdi: tweak task dirty penalty
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Fri Feb 27 10:41:22 CET 2009
>
> Penalizing heavy dirtiers with 1/8-th the total dirty limit might be rather
> excessive on large memory machines. Use sqrt to scale it sub-linearly.
>
> Update the comment while we're there.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> ---
> mm/page-writeback.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> Index: linux-2.6/mm/page-writeback.c
> ===================================================================
> --- linux-2.6.orig/mm/page-writeback.c
> +++ linux-2.6/mm/page-writeback.c
> @@ -293,17 +293,21 @@ static inline void task_dirties_fraction
> }
>
> /*
> - * scale the dirty limit
> + * Task specific dirty limit:
> *
> - * task specific dirty limit:
> + * dirty -= 8 * sqrt(dirty) * p_{t}
> *
> - * dirty -= (dirty/8) * p_{t}
> + * Penalize tasks that dirty a lot of pages by lowering their dirty limit. This
> + * avoids infrequent dirtiers from getting stuck in this other guys dirty
> + * pages.
> + *
> + * Use a sub-linear function to scale the penalty, we only need a little room.
> */
> static void task_dirty_limit(struct task_struct *tsk, long *pdirty)
> {
> long numerator, denominator;
> long dirty = *pdirty;
> - u64 inv = dirty >> 3;
> + u64 inv = 8*int_sqrt(dirty);
>
> task_dirties_fraction(tsk, &numerator, &denominator);
> inv *= numerator;
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iozone regression with 2.6.29-rc6
2009-02-27 9:49 ` Peter Zijlstra
2009-02-27 11:55 ` Nick Piggin
@ 2009-03-02 2:19 ` Lin Ming
2009-03-02 3:12 ` Wu Fengguang
1 sibling, 1 reply; 6+ messages in thread
From: Lin Ming @ 2009-03-02 2:19 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: npiggin, linux-kernel, Zhang, Yanmin
On Fri, 2009-02-27 at 17:49 +0800, Peter Zijlstra wrote:
> On Fri, 2009-02-27 at 17:13 +0800, Lin Ming wrote:
> > bisect locates below commits,
> >
> > commit 1cf6e7d83bf334cc5916137862c920a97aabc018
> > Author: Nick Piggin <npiggin@suse.de>
> > Date: Wed Feb 18 14:48:18 2009 -0800
> >
> > mm: task dirty accounting fix
> >
> > YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
> > cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
> >
> > Additionally, there is some inconsistency about when task_dirty_inc is
> > called. It is used for dirty balancing, however it even gets called for
> > __set_page_dirty_no_writeback.
> >
> > So rather than increment it in a set_page_dirty wrapper, move it down to
> > exactly where the dirty page accounting stats are incremented.
> >
> > Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
> > Signed-off-by: Nick Piggin <npiggin@suse.de>
> > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> >
> >
> > below data in parenthesis is the result after above commit reverted, for example,
> > -10% (+2%) means,
> > iozone has ~10% regression with 2.6.29-rc6 compared with 2.6.29-rc5.
> > and
> > iozone has ~2% improvement with 2.6.29-rc6-revert-1cf6e7d compared with 2.6.29-rc5.
> >
> >
> > 4P dual-core HT 2P qual-core 2P qual-core HT
> > tulsa stockley Nehalem
> > --------------------------------------------------------
> > iozone-rewrite -10% (+2%) -8% (0%) -10% (-7%)
> > iozone-rand-write -50% (0%) -20% (+10%)
> > iozone-read -13% (0%)
> > iozone-write -28% (-1%)
> > iozone-reread -5% (-1%)
> > iozone-mmap-read -7% (+2%)
> > iozone-mmap-reread -7% (+2%)
> > iozone-mmap-rand-read -7% (+3%)
> > iozone-mmap-rand-write -5% (0%)
>
> Ugh, that's unexpected..
>
> So 'better' accounting leads to worse performance, which would indicate
> we throttle more.
>
> I take it you machine has gobs of memory.
>
> Does something like the below help any?
It helps some as below test result,
The data in second parenthesis means 2.6.29-rc6-with-peter's-patch
compared with 2.6.29-rc5.
4P dual-core HT 2P qual-core 2P qual-core HT
tulsa stockley Nehalem
--------------------------------------------------------
iozone-rewrite -10% (+2%)(-3%) -8% (0%)(0%) -10% (-7%)(-2%)
iozone-rand-write -50% (0%)(-10%) -20% (+10%)(+3%)
iozone-read -13% (0%)(-8%)
iozone-write -28% (-1%)(+35%)
iozone-reread -5% (-1%)(-1%)
iozone-mmap-read -7% (+2%)(-7%)
iozone-mmap-reread -7% (+2%)(-7%)
iozone-mmap-rand-read -7% (+3%)(-7%)
iozone-mmap-rand-write -5% (0%)(+27%)
Lin Ming
>
> ---
> Subject: mm: bdi: tweak task dirty penalty
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Fri Feb 27 10:41:22 CET 2009
>
> Penalizing heavy dirtiers with 1/8-th the total dirty limit might be rather
> excessive on large memory machines. Use sqrt to scale it sub-linearly.
>
> Update the comment while we're there.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> ---
> mm/page-writeback.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> Index: linux-2.6/mm/page-writeback.c
> ===================================================================
> --- linux-2.6.orig/mm/page-writeback.c
> +++ linux-2.6/mm/page-writeback.c
> @@ -293,17 +293,21 @@ static inline void task_dirties_fraction
> }
>
> /*
> - * scale the dirty limit
> + * Task specific dirty limit:
> *
> - * task specific dirty limit:
> + * dirty -= 8 * sqrt(dirty) * p_{t}
> *
> - * dirty -= (dirty/8) * p_{t}
> + * Penalize tasks that dirty a lot of pages by lowering their dirty limit. This
> + * avoids infrequent dirtiers from getting stuck in this other guys dirty
> + * pages.
> + *
> + * Use a sub-linear function to scale the penalty, we only need a little room.
> */
> static void task_dirty_limit(struct task_struct *tsk, long *pdirty)
> {
> long numerator, denominator;
> long dirty = *pdirty;
> - u64 inv = dirty >> 3;
> + u64 inv = 8*int_sqrt(dirty);
>
> task_dirties_fraction(tsk, &numerator, &denominator);
> inv *= numerator;
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iozone regression with 2.6.29-rc6
2009-03-02 2:19 ` Lin Ming
@ 2009-03-02 3:12 ` Wu Fengguang
2009-03-02 3:16 ` Lin Ming
0 siblings, 1 reply; 6+ messages in thread
From: Wu Fengguang @ 2009-03-02 3:12 UTC (permalink / raw)
To: Lin Ming; +Cc: Peter Zijlstra, npiggin, linux-kernel, Zhang, Yanmin
On Mon, Mar 02, 2009 at 10:19:04AM +0800, Lin, Ming wrote:
> On Fri, 2009-02-27 at 17:49 +0800, Peter Zijlstra wrote:
> > On Fri, 2009-02-27 at 17:13 +0800, Lin Ming wrote:
> > > bisect locates below commits,
> > >
> > > commit 1cf6e7d83bf334cc5916137862c920a97aabc018
> > > Author: Nick Piggin <npiggin@suse.de>
> > > Date: Wed Feb 18 14:48:18 2009 -0800
> > >
> > > mm: task dirty accounting fix
> > >
> > > YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
> > > cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
> > >
> > > Additionally, there is some inconsistency about when task_dirty_inc is
> > > called. It is used for dirty balancing, however it even gets called for
> > > __set_page_dirty_no_writeback.
> > >
> > > So rather than increment it in a set_page_dirty wrapper, move it down to
> > > exactly where the dirty page accounting stats are incremented.
> > >
> > > Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
> > > Signed-off-by: Nick Piggin <npiggin@suse.de>
> > > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > >
> > >
> > > below data in parenthesis is the result after above commit reverted, for example,
> > > -10% (+2%) means,
> > > iozone has ~10% regression with 2.6.29-rc6 compared with 2.6.29-rc5.
> > > and
> > > iozone has ~2% improvement with 2.6.29-rc6-revert-1cf6e7d compared with 2.6.29-rc5.
> > >
> > >
> > > 4P dual-core HT 2P qual-core 2P qual-core HT
> > > tulsa stockley Nehalem
> > > --------------------------------------------------------
> > > iozone-rewrite -10% (+2%) -8% (0%) -10% (-7%)
> > > iozone-rand-write -50% (0%) -20% (+10%)
> > > iozone-read -13% (0%)
> > > iozone-write -28% (-1%)
> > > iozone-reread -5% (-1%)
> > > iozone-mmap-read -7% (+2%)
> > > iozone-mmap-reread -7% (+2%)
> > > iozone-mmap-rand-read -7% (+3%)
> > > iozone-mmap-rand-write -5% (0%)
> >
> > Ugh, that's unexpected..
> >
> > So 'better' accounting leads to worse performance, which would indicate
> > we throttle more.
> >
> > I take it you machine has gobs of memory.
> >
> > Does something like the below help any?
>
> It helps some as below test result,
> The data in second parenthesis means 2.6.29-rc6-with-peter's-patch
> compared with 2.6.29-rc5.
>
> 4P dual-core HT 2P qual-core 2P qual-core HT
> tulsa stockley Nehalem
> --------------------------------------------------------
> iozone-rewrite -10% (+2%)(-3%) -8% (0%)(0%) -10% (-7%)(-2%)
> iozone-rand-write -50% (0%)(-10%) -20% (+10%)(+3%)
> iozone-read -13% (0%)(-8%)
> iozone-write -28% (-1%)(+35%)
> iozone-reread -5% (-1%)(-1%)
> iozone-mmap-read -7% (+2%)(-7%)
> iozone-mmap-reread -7% (+2%)(-7%)
> iozone-mmap-rand-read -7% (+3%)(-7%)
> iozone-mmap-rand-write -5% (0%)(+27%)
Thanks, Lin Ming. To better understand the situation, would you please
provide the iozone command and memory info about the servers?
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iozone regression with 2.6.29-rc6
2009-03-02 3:12 ` Wu Fengguang
@ 2009-03-02 3:16 ` Lin Ming
0 siblings, 0 replies; 6+ messages in thread
From: Lin Ming @ 2009-03-02 3:16 UTC (permalink / raw)
To: Wu, Fengguang; +Cc: Peter Zijlstra, npiggin, linux-kernel, Zhang, Yanmin
On Mon, 2009-03-02 at 11:12 +0800, Wu, Fengguang wrote:
> On Mon, Mar 02, 2009 at 10:19:04AM +0800, Lin, Ming wrote:
> > On Fri, 2009-02-27 at 17:49 +0800, Peter Zijlstra wrote:
> > > On Fri, 2009-02-27 at 17:13 +0800, Lin Ming wrote:
> > > > bisect locates below commits,
> > > >
> > > > commit 1cf6e7d83bf334cc5916137862c920a97aabc018
> > > > Author: Nick Piggin <npiggin@suse.de>
> > > > Date: Wed Feb 18 14:48:18 2009 -0800
> > > >
> > > > mm: task dirty accounting fix
> > > >
> > > > YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
> > > > cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
> > > >
> > > > Additionally, there is some inconsistency about when task_dirty_inc is
> > > > called. It is used for dirty balancing, however it even gets called for
> > > > __set_page_dirty_no_writeback.
> > > >
> > > > So rather than increment it in a set_page_dirty wrapper, move it down to
> > > > exactly where the dirty page accounting stats are incremented.
> > > >
> > > > Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
> > > > Signed-off-by: Nick Piggin <npiggin@suse.de>
> > > > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > > > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > > >
> > > >
> > > > below data in parenthesis is the result after above commit reverted, for example,
> > > > -10% (+2%) means,
> > > > iozone has ~10% regression with 2.6.29-rc6 compared with 2.6.29-rc5.
> > > > and
> > > > iozone has ~2% improvement with 2.6.29-rc6-revert-1cf6e7d compared with 2.6.29-rc5.
> > > >
> > > >
> > > > 4P dual-core HT 2P qual-core 2P qual-core HT
> > > > tulsa stockley Nehalem
> > > > --------------------------------------------------------
> > > > iozone-rewrite -10% (+2%) -8% (0%) -10% (-7%)
> > > > iozone-rand-write -50% (0%) -20% (+10%)
> > > > iozone-read -13% (0%)
> > > > iozone-write -28% (-1%)
> > > > iozone-reread -5% (-1%)
> > > > iozone-mmap-read -7% (+2%)
> > > > iozone-mmap-reread -7% (+2%)
> > > > iozone-mmap-rand-read -7% (+3%)
> > > > iozone-mmap-rand-write -5% (0%)
> > >
> > > Ugh, that's unexpected..
> > >
> > > So 'better' accounting leads to worse performance, which would indicate
> > > we throttle more.
> > >
> > > I take it you machine has gobs of memory.
> > >
> > > Does something like the below help any?
> >
> > It helps some as below test result,
> > The data in second parenthesis means 2.6.29-rc6-with-peter's-patch
> > compared with 2.6.29-rc5.
> >
> > 4P dual-core HT 2P qual-core 2P qual-core HT
> > tulsa stockley Nehalem
> > --------------------------------------------------------
> > iozone-rewrite -10% (+2%)(-3%) -8% (0%)(0%) -10% (-7%)(-2%)
> > iozone-rand-write -50% (0%)(-10%) -20% (+10%)(+3%)
> > iozone-read -13% (0%)(-8%)
> > iozone-write -28% (-1%)(+35%)
> > iozone-reread -5% (-1%)(-1%)
> > iozone-mmap-read -7% (+2%)(-7%)
> > iozone-mmap-reread -7% (+2%)(-7%)
> > iozone-mmap-rand-read -7% (+3%)(-7%)
> > iozone-mmap-rand-write -5% (0%)(+27%)
>
> Thanks, Lin Ming. To better understand the situation, would you please
> provide the iozone command and memory info about the servers?
iozone -i 0 -i 1 -i 2 -i 3 -i 4 -r 4k -s 64k -s 512m -s 1200m -b tmp.xls
iozone -B -r 4k -s 64k -s 512m -s 1200m -b tmp.xls
4P dual-core HT tulsa /proc/meminfo
------------------------------------
MemTotal: 8189476 kB
MemFree: 7915884 kB
Buffers: 32676 kB
Cached: 139784 kB
SwapCached: 0 kB
Active: 35852 kB
Inactive: 145564 kB
Active(anon): 9048 kB
Inactive(anon): 0 kB
Active(file): 26804 kB
Inactive(file): 145564 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 140 kB
Writeback: 0 kB
AnonPages: 9068 kB
Mapped: 4084 kB
Slab: 31180 kB
SReclaimable: 14800 kB
SUnreclaim: 16380 kB
PageTables: 1236 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 4094736 kB
Committed_AS: 18446744073709545248 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 286416 kB
VmallocChunk: 34359449467 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 4096 kB
DirectMap2M: 8380416
2P qual-core stockley /proc/meminfo
-----------------------------------
MemTotal: 8167260 kB
MemFree: 7951068 kB
Buffers: 30988 kB
Cached: 123772 kB
SwapCached: 0 kB
Active: 34744 kB
Inactive: 129296 kB
Active(anon): 9412 kB
Inactive(anon): 0 kB
Active(file): 25332 kB
Inactive(file): 129296 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 272 kB
Writeback: 0 kB
AnonPages: 9408 kB
Mapped: 4072 kB
Slab: 21760 kB
SReclaimable: 10612 kB
SUnreclaim: 11148 kB
PageTables: 1260 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 4083628 kB
Committed_AS: 18446744073709540996 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 11216 kB
VmallocChunk: 34359726459 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 7168 kB
DirectMap2M: 8380416 kB
2P qual-core HT Nehalem /proc/meminfo
-------------------------------------
MemTotal: 6113044 kB
MemFree: 5947476 kB
Buffers: 17056 kB
Cached: 44280 kB
SwapCached: 0 kB
Active: 31268 kB
Inactive: 40300 kB
Active(anon): 10308 kB
Inactive(anon): 0 kB
Active(file): 20960 kB
Inactive(file): 40300 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 280 kB
Writeback: 0 kB
AnonPages: 10328 kB
Mapped: 5096 kB
Slab: 27844 kB
SReclaimable: 10988 kB
SUnreclaim: 16856 kB
PageTables: 2204 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3056520 kB
Committed_AS: 18446744073709542732 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 286428 kB
VmallocChunk: 34359451259 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 8192 kB
DirectMap2M: 6275072 kB
Lin Ming
>
> Thanks,
> Fengguang
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-03-02 3:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-27 9:13 iozone regression with 2.6.29-rc6 Lin Ming
2009-02-27 9:49 ` Peter Zijlstra
2009-02-27 11:55 ` Nick Piggin
2009-03-02 2:19 ` Lin Ming
2009-03-02 3:12 ` Wu Fengguang
2009-03-02 3:16 ` Lin Ming
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).