Stano,
[..] A general question: I am seeing a few recent changes in the tracing code. Is it generally safe to have at least latency histogram enabled in the production code, or is it advised not to compile these features in? I'd like to see the latencies the customer is getting in the real environment, but if the code is considered as work-in-progress, it is better to play it safe.
There are a number of different built-in latency histograms in the kernel, some of them are best used to trace a known problem (e.g. INTERRUPT_OFF_HIST and PREEMPT_OFF_HIST) while others are intended for continuous latency monitoring (CONFIG_WAKEUP_LATENCY_HIST and CONFIG_MISSED_TIMER_OFFSETS_HIST). The latter are ideally suitable to document the real-time capabilities of a production system and to retrospectively analyze a failure that may be related to a prolonged latency. We, therefore, configure and enable continuous latency monitoring histograms (CONFIG_WAKEUP_LATENCY_HIST and CONFIG_MISSED_TIMER_OFFSETS_HIST) by default in all our farm systems since more than two years (https://www.osadl.org/?id=864), and we are not aware of any problem that might be related to them. I, thus, would like to say that they are save to be used in production systems. Since we do not have much long-term experience with the other histograms and they may introduce additional and longer latencies than the former, I would not recommend to enable them in production systems. BTW: Your question was whether it is "advised not to compile these features in". There certainly is very little penalty or risk to configure these features without enabling them. So I don't see any reason not to compile them in. Only when you enable them cd /sys/kernel/debug/tracing/latency_hist/enable for i in wakeup missed_timer_offsets timerandwakeup do echo 1 >$i done a certain latency penalty and risk of malfunction may apply. -Carsten. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
