[Bug runtime/20286] New: probe handlers using hrtimers taking too long

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20286

            Bug ID: 20286
           Summary: probe handlers using hrtimers taking too long
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

When running the full testsuite (in parallel mode, but I'm not sure it
matters), I see the following on the console (3.10.0-442.el7.ppc64):

[ 6881.740026] hrtimer: interrupt took 3721 ns

While that doesn't look too alarming, what it means is that the next timer has
already expired because the current timer callback took too long. I'm looking
at the source of hrtimer_interrupt() in kernel/time/hrtimer.c. Here's a comment
from there:

         * The next timer was already expired due to:
         * - tracing
         * - long lasting callbacks
         * - being scheduled away when running in a VM
         *
         * We need to prevent that we loop forever in the hrtimer
         * interrupt routine. We give it 3 attempts to avoid
         * overreacting on some spurious event.

We may need to lower MAXACTION for probes that use hrtimers or think of some
other way to not take too long in an hrtimer-based probe. This probably should
depend on the timer's frequency (i.e. the faster the timer, the less actions
should be allowed).

-- 
You are receiving this mail because:
You are the assignee for the bug.