Re: timerfd read does not return - was probably fixed in 3.4.38

[Carsten Emde <C.Emde@osadl.org>]

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.