[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070711174759.GA17471@elte.hu>
Date: Wed, 11 Jul 2007 19:47:59 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Martin Bligh <mbligh@...igh.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andy Whitcroft <apw@...dowen.org>
Subject: Re: Performance regression in 2.6.22-git1 (new sched code?)
* Ingo Molnar <mingo@...e.hu> wrote:
> > http://test.kernel.org/perf/kernbench.elm3b132.png
>
> thx! I'll check this tomorrow, meanwhile here are a few quick ideas.
ok, i've re-tested this, and could you please try the fix attached
below, combined with a CONFIG_HZ=100 run and with SCHED_DEBUG disabled?
I think a fair bit of the overhead comes from granularity being capped
to 10 msecs instead of the intended 100 msecs.
Ingo
--------------------------------------------->
Subject: [patch] sched: allow larger granularity
From: Ingo Molnar <mingo@...e.hu>
allow granularity up to 100 msecs, instead of 10 msecs.
(needed on larger boxes)
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4772,7 +4772,7 @@ cpumask_t nohz_cpu_mask = CPU_MASK_NONE;
static inline void sched_init_granularity(void)
{
unsigned int factor = 1 + ilog2(num_online_cpus());
- const unsigned long gran_limit = 10000000;
+ const unsigned long gran_limit = 100000000;
sysctl_sched_granularity *= factor;
if (sysctl_sched_granularity > gran_limit)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists