* 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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
