[patch] voluntary-preempt-2.6.8-rc4-O7

[Ingo Molnar]

* Lee Revell <rlrevell@xxxxxxxxxxx> wrote:

> Here's another weird one.  This happens when you create a new tab in
> gnome-terminal, which causes a fork().
> 
> preemption latency trace v1.0
> -----------------------------
>  latency: 613 us, entries: 697 (697)
>  process: gnome-terminal/3467, uid: 1000
>  nice: 0, policy: 0, rt_priority: 0
> =======>

>  0.459ms (+0.000ms): preempt_schedule (copy_page_range)
>  0.459ms (+0.000ms): preempt_schedule (copy_page_range)
>  0.460ms (+0.000ms): preempt_schedule (copy_page_range)
>  0.461ms (+0.000ms): preempt_schedule (copy_page_range)

ok, it seems the lock-break of the outer loop was not enough - the up to
1024 iterations in the inner loop can generate quite high latencies too.

in -O7 i've added a runtime flag to disable/enable tracing without
having to recompile the kernel:

 http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc4-O7

/proc/sys/kernel/tracing_enabled controls whether full tracing is done
or not. (some overhead still occurs due to the instrumentation but most
of the tracing overhead should vanish.)

It would be nice to check whether the same overhead occurs with tracing
disabled too - the copy_page_range() loop could be one piece of code
that could get roughly twice as slow with tracing enabled as with
tracing disabled. But 300 usecs is too much too.

-O7 also adds your EXPORT_SYMBOL fix and Peter Zijlstra's compilation
fix.

	Ingo
-
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/