This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/20286] New: probe handlers using hrtimers taking too long
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 21 Jun 2016 20:39:04 +0000
- Subject: [Bug runtime/20286] New: probe handlers using hrtimers taking too long
- Auto-submitted: auto-generated
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.