This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug runtime/2514] New: Sequence had xxx drops.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]