fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
orivej has quit [Ping timeout: 276 seconds]
wmealing has joined #systemtap
* wmealing
waves
<wmealing>
dont need anything
<promach>
fche: means that you cannot reproduce the problem at my own computer
<promach>
let me reinstall systemtap
<promach>
fche: it seems like we need to use --example linetimes.stp
<promach>
and '*' <-- what is this for ?
<promach>
fche: and I saw a lot of blacklisted functions warnings
<fche>
a function-by-function one obviously has less cost (since those are less frequent)
<fche>
that last paste url still has the -p4, so the script is not being run
<fche>
drop the -p4 and try again
<promach>
yeah, -p5 will give the same error as well, since we need stage 4 before stage 5
<fche>
the second ('*') -p4 run succeeded though
<promach>
why is that so ?
<fche>
maybe something is wrong only with the push_circ_queue function only
<fche>
try a wildcard like 'push*' ?
* fche
must head off for about 40 mins
<fche>
also try function level traces first. or a single module(...).statement("*@file.c:2323") type line probe, located within the function of interest
<fche>
also try stap -L 'module("...").statement("...")' to generate lists of available probe points
<promach>
fche : wildcard does not work with linetimes.stp
vush has joined #systemtap
<vush>
hello #systemtap. I am working on a virtual machine in ubuntu 18.04 and have a problem with systemtap saying "semantic error: while resolving probe point: identifier 'module' ... source: probe module("evdev").(...) semantic error: no match;
<vush>
I'm thinking it is the module evdev missing and suspect it's because of some VM-Emulation maybe. I have not found an article about this, only kernel wise
<fche>
vush, one persistent problem with ubuntu is the difficulty of installing matching debuginfo
<fche>
but if you can get it (and #stap-prep may help), things should work okay
<fche>
promach, I offered a list of stap scripts because they may help you make progress even while we diagnose the exact problem with this particular function
<fche>
by the way, have you tried sudo stap -vv --example linetimes.stp 'module("/lib/modules/4.18.6-041806-generic/kernel/drivers/riffa/riffa.ko")' '*'
<fche>
it should at least launch, but depending on traffic, might hit the overload-detection limits. it'll tell you if it does.
<promach>
let me dig deeper. give me some time. I am learning stap
<promach>
overload-detection limit ??
<fche>
promach, absolutely, thanks for hanging with it
<promach>
this stap script is introducing too much timing overhead to giga-speed PCIe linux driver
<fche>
see [man stap] re. --suppress-time-limits
<fche>
ok, so you did get it running, but has high impact? ok, that makes sense if it's probing too much
<fche>
(the kernel makes each probe hit cost O(100ns) as pure overhead)
<promach>
fche: too high timing overhead impact
<fche>
ok, so one needs to be more selective in the probing
<promach>
but I got an overall idea where the timing critical functions are
<fche>
function- rather than statement-level tracing for initial investigation is a good idea
<promach>
function- rather than statement-level tracing ??
<promach>
you mean do not use linetimes.stp for initial investigation ?
<fche>
correct, if I wanted to know function-level timing data, I'd start with function-level tracing data
<promach>
how would I do that ?
<fche>
by using a different stap script, one that probes functions mainly rather than statements within functions
<fche>
so that gives you calls and returns to/from that function
<fche>
t
<fche>
the left column is an estimated microsecond elapsed time from call to return
<fche>
it pretty-prints the function parameters a little bit (para-callgraph-verbose prints them more verbosely)
<fche>
you can drop the -vv if things are generally working
<promach>
fche: thanks a lot !!!
wcohen has joined #systemtap
<fche>
promach, yeah, you can do other things to, like with the eventcount.stp see rates of events (like module("..").function("*").call s), like a profile but traced/counted rather than sampled
<vush>
fche, right now I didn't try to compile a kernel or something. but 2-3 stap examples i have tried are working. it looks like including 'some?' (evdev) modules is not working
<fche>
maybe evdev is compiled right into the kernel? then module("evdev").* should be replaced by kernel.* in your scripts