This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/2514] New: Sequence had xxx drops.
- From: "guanglei at cn dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 5 Apr 2006 14:31:39 -0000
- Subject: [Bug runtime/2514] New: Sequence had xxx drops.
- Reply-to: sourceware-bugzilla at sourceware dot org
In the early overhead testing stage of LKET, we only use syscall event hook to
trace the execution of some benchmark tools, and we found at the end of testing,
SystemTap will give a report of "Sequence had xxx drops". But the drops of
sequence is only several hunderds.
But as we begin to use more than one event hooks to trace the benchmark tools,
the number of dropped sequence increase greatly, e.g, the testing of dbench shows:
...
Sequence had 8667222 drops.
total hooks triggered is 11087355
Such a big drop number is unbearable, and it will even cause the final trace
data useless at all.
One reason I guess is that in such a heavy loaded system, the probe handlers are
triggered in a very high freq and generates too much data to be handled by
relayfs. The speed of putting into relayfs transport layer is much faster than
the speed that those data are retrieved away from relayfs from user space.
So are there any ways of fixing this? It is a problem for the trace tool like
LKET which will generate a very large trace data file.
--
Summary: Sequence had xxx drops.
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: runtime
AssignedTo: systemtap at sources dot redhat dot com
ReportedBy: guanglei at cn dot ibm dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=2514
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.