Re: Performance regression in 2.6.22-git1 (new sched code?)

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxx> 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@xxxxxxx>

allow granularity up to 100 msecs, instead of 10 msecs.
(needed on larger boxes)

Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
---
 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/