* Ingo Molnar <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
allow granularity up to 100 msecs, instead of 10 msecs.
(needed on larger boxes)
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
