aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorCarsten Emde <Carsten.Emde@osadl.org>2009-10-25 19:47:17 -0400
committerThomas Gleixner <tglx@linutronix.de>2009-11-06 06:31:35 -0500
commit16731e6ff7c29c4f1a3dc7d4f42ce61e8e4a2f6d (patch)
treef2d146511a8d5629c6bdbc17de073c461c542687 /include/linux
parentd9a4a1d04d0b5ba138a6a5b25013187d4614de4d (diff)
ftrace: Consider shared max priority in latency histograms
The algorithm used so far to trace the process with the highest priority requires that no other processes with the same priority are being woken up simultaneously. Otherwise, a process with a lower priority may be picked up for tracing which leads to an erroneously high latency value. Generally, the wakeup latency of a process that exclusively uses the highest priority of the system is due to software or hardware issues we would like to solve or, at least, keep as small as possible. This is what latency measurements are made for, after all. The wakeup latency of a process that shares the highest priority of the system with other processes, is quite another story. It may contain the worst-case runtime durations of the other processes; thus, it is the result of the priority design of a given system and nothing a kernel developer or hardware engineer may want to fix. This said, we need to separately record latencies i) of processes that exclusively use the highest priority of the system and ii) of processes that share the highest priority of the system with other processes. The above mentioned shortcoming of the tracing algorithm also applies to the variable tracing_max_latency that the wakeup latency tracer uses, since it is based on the same procedure as the original version of the latency histogram. In consequence, if several processes share the highest priority of the system, the variable tracing_max_latency may contain erroneously high values. We could now patch the wakeup latency tracer as well and separately record the various latencies, but we better document this behavior and recommend the latency histograms to reliably determine a system's worst-case wakeup latency. Simplified and cleaned up a bit. Added some more help info to Kconfig. Signed-off-by: Carsten Emde <C.Emde@osadl.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'include/linux')
-rw-r--r--include/linux/sched.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/include/linux/sched.h b/include/linux/sched.h
index c231a2467a83..676126d56894 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1548,6 +1548,9 @@ struct task_struct {
1548 unsigned long trace; 1548 unsigned long trace;
1549 /* bitmask of trace recursion */ 1549 /* bitmask of trace recursion */
1550 unsigned long trace_recursion; 1550 unsigned long trace_recursion;
1551#ifdef CONFIG_WAKEUP_LATENCY_HIST
1552 u64 preempt_timestamp_hist;
1553#endif
1551#endif /* CONFIG_TRACING */ 1554#endif /* CONFIG_TRACING */
1552#ifdef CONFIG_PREEMPT_RT 1555#ifdef CONFIG_PREEMPT_RT
1553 /* 1556 /*