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: 246 seconds]
orivej has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
hpt has joined #systemtap
pviktori has quit [Ping timeout: 256 seconds]
<agentzh>
fche: hi
<agentzh>
i wonder if it's possible to do wall-clock time.profile in stap. like using utrace attach and a timer.ms(N) ?
<agentzh>
it's against a userland process.
<fche>
wall-clock?
orivej has quit [Quit: No Ping reply in 180 seconds.]
<agentzh>
timer.profile is for CPU sampling, not for real time.
<fche>
timer.ms is already wall clock
<agentzh>
but timer.ms is not necessarily in the target process context.
<agentzh>
actually usually it's not when the target process is sleeping.
<fche>
there is timer.profile.freq.hz(N)
orivej has joined #systemtap
<agentzh>
but it's not in the target process context?
<agentzh>
not necessarily i mean
<fche>
it should be, if the target process is on cpu at the time
<fche>
(so you filter on pid() etc.)
<agentzh>
hmm, what if it's not on cpu?
<agentzh>
like sleeping?
<fche>
then it won't get hit
<agentzh>
that's why i need this in the first place :)
<fche>
but then you don't mean wall-clock profiling
<fche>
you mean proces cpu-time profiling
<agentzh>
actually i do. process waiting for io or locks still count as "time".
<agentzh>
i hope to do profiling on the wall clock time for the target process.
<fche>
ok then there is no context available when they're sleeping
<fche>
the cpu's busy doing something else at that time
<agentzh>
utrace attach should work here?
<agentzh>
like process.begin()?
<agentzh>
i could for example, calling a .stp script using process.begin() repeatedly from an external shell script sleeping with fixed internvals.
<fche>
I bet we don't want to / can't do blocky things like simulated-utrace operations on processes, from a timer callback
<agentzh>
like while true; do staprun sample.ko; sleep 0.1; done
<agentzh>
but the overhead of staprun is not excluded.
<fche>
EWW
<agentzh>
oh, yeah, that's true.
<fche>
well ... why not probe timer.profile { if pid() != my_interesting_pid next }
<agentzh>
timer contexts are like interrupts.
<agentzh>
or they *are* interrupts.
<fche>
yeah
<agentzh>
yeah, we already do timer.profile but that's for "hot" cpu-time sampling.
<agentzh>
which does not include io time or mutex time.
<fche>
you can synthesize that info from tracking when/why processes go off/on cpu
<agentzh>
seems like a shell loop with sleeps is the only way to go now...
<agentzh>
oh yeah, using scheduler.cpu_{on,off} probes.
<agentzh>
just maybe a little bit more overhead.
<fche>
more than running staprun etc. many times a second? probably not
<agentzh>
since we are doing full instrumentation instead of timed sampling.
<agentzh>
agreed. staprun is much more expensive.
<fche>
it doesn't have to be heavy at those tracepoints
<agentzh>
yep
<agentzh>
let me think about how to synthesize cpu sampling & off cpu time tracking.
<agentzh>
timer.profile is not based on real time...so maybe kinda tricky to combine.
<fche>
(technically if you track on/off events AND TIMES you don't need the timer.profile)
<agentzh>
hmm, but the code paths would change during the CPU interval.
<agentzh>
*on-CPU interval
<agentzh>
unlike the off CPU time intervals where the backtrace cannot change.
<agentzh>
so we still need some perspective betwwn on-cpu and off-cpu backtraces in terms of wall clock time.
<fche>
right
<agentzh>
*between
<agentzh>
okay, maybe i can count the number of probe hits in the on-cpu internvals triggered by timer.profile and do the maths.
<agentzh>
assuming timer.profile is fired evenly during those on-cpu intervals.
<agentzh>
is it?
<agentzh>
:)
<agentzh>
maybe a bit tricky on a SMP system.
<agentzh>
oh silly me i can always use get_timeofday_us() in those timer.profile probe handlers.
<fche>
yup
<fche>
see also perf.sw.task_clock probes
<agentzh>
that should be a good enough first-order approximation.
<agentzh>
oh, nice.
<agentzh>
that sould be better.
<agentzh>
more evenly.
<fche>
maybe :)
<agentzh>
i'll try it out. thanks.
orivej_ has joined #systemtap
orivej has quit [Ping timeout: 264 seconds]
orivej_ has quit [Ping timeout: 256 seconds]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has joined #systemtap
khaled has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
pviktori has joined #systemtap
mjw has joined #systemtap
jistone has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 246 seconds]
jistone has joined #systemtap
hpt has quit [Quit: Lost terminal]
gregwork has quit [Quit: Connection closed for inactivity]
orivej has joined #systemtap
amerey has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 240 seconds]
khaled has quit [Ping timeout: 258 seconds]
khaled has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #systemtap
sapatel has joined #systemtap
derek0883 has joined #systemtap
orivej_ has quit [Ping timeout: 264 seconds]
orivej has joined #systemtap
tromey has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
orivej_ has joined #systemtap
orivej has quit [Ping timeout: 264 seconds]
amerey has quit [Quit: Leaving]
amerey has joined #systemtap
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
amerey has quit [Remote host closed the connection]
amerey has joined #systemtap
amerey has quit [Client Quit]
amerey has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
amerey has quit [Quit: Leaving]
amerey has joined #systemtap
amerey has quit [Client Quit]
amerey has joined #systemtap
amerey_ has joined #systemtap
amerey_ has quit [Client Quit]
derek0883 has quit [Ping timeout: 264 seconds]
derek0883 has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
mjw has quit [Quit: Leaving]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
derek088_ has joined #systemtap
derek088_ has quit [Remote host closed the connection]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
<irker807>
systemtap: fche systemtap.git:master * release-4.3-24-g37066e2c3 / buildrun.cxx runtime/linux/access_process_vm.h runtime/linux/autoconf-mmap_lock.c runtime/linux/stap_mmap_lock.h runtime/linux/task_finder2.c: PR26142: adapt to linux mmap_sem api transition
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
<irker807>
systemtap: fche systemtap.git:master * release-4.3-25-g79000b42e / runtime/linux/runtime.h: PR26142: Adapt to linux/vermagic.h file hiding ... but not on rhel6