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: 264 seconds]
hpt has joined #systemtap
sanoj has joined #systemtap
orivej has joined #systemtap
hpt has quit [Quit: Lost terminal]
hpt has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
slowfranklin has joined #systemtap
mjw has joined #systemtap
pwithnall has joined #systemtap
orivej has joined #systemtap
hpt has quit [Ping timeout: 248 seconds]
scox has quit [Ping timeout: 260 seconds]
sanoj has quit [Ping timeout: 248 seconds]
sanoj has joined #systemtap
wcohen has quit [Ping timeout: 276 seconds]
scox has joined #systemtap
sanoj has quit [Ping timeout: 260 seconds]
wcohen has joined #systemtap
drsmith has left #systemtap [#systemtap]
drsmith has joined #systemtap
tromey has joined #systemtap
gromero has joined #systemtap
gromero has quit [Read error: Connection reset by peer]
gromero_ has joined #systemtap
brolley has joined #systemtap
orivej has quit [Ping timeout: 264 seconds]
pwithnall has quit [Quit: pwithnall]
pwithnall has joined #systemtap
dhaibhidh has joined #systemtap
<dhaibhidh>
I'm finding an issue where if I define more than one probe either at function calls within a single function or statements within a function, only the first probe seems to take be triggered. Subsequent probes can be triggered but at much lower frequency. Is this expected behavior?
hotwire007 has joined #systemtap
<fche2>
not really - assuming that the function you're probing is straight-through - that there isn't another explanation like control flow differences to explain the probe rates
<fche2>
that said, there was a kernel bug a couple of months ago that manifested itself with probes being enabled or disabled depending on the order in which they were registered (-> listed in the .stp file)
<dhaibhidh>
This might be my case, the first probe, i.e highest in the file is the one that takes effect.
<fche2>
run with stap -t ... to see hit counts at shutdown
<fche2>
could use the eventcount.stp
<fche2>
sample to see rates live
<dhaibhidh>
Adding stap -t the hit rates and the output look correct.