Messages in this thread | | | Date | Fri, 13 Aug 2004 12:48:17 +0200 | From | Ingo Molnar <> | Subject | [patch] voluntary-preempt-2.6.8-rc4-O7 |
| |
* Lee Revell <rlrevell@joe-job.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |