fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has joined #systemtap
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #systemtap
<linus2>
fche: there are str1 = "m123n" str2 = "m456n"
<linus2>
Might it using a macro to replace 123 and 456 position?
<linus2>
such as str1 = "m$NUMn" str2 = "m$numn"?
<linus2>
#define $NUM 789
<linus2>
then replace all str1 and str2's $NUM?
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
sscox has quit [Ping timeout: 265 seconds]
sscox has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
_whitelogger has joined #systemtap
khaled has joined #systemtap
_whitelogger has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
<linus2>
fche: are you here?
<linus2>
fche: the global variable in stp script is shared by all thread and when the same probe hitted in different thread could modify the global variable, right?
<fche>
linus2, probably construct the newstring via sprintf ("m%dn", num)
<fche>
yes reading / writing the global variable is a-ok and automatically lock-protected
<linus2>
but when I use gettimeofday_us() in openmp parallel region, it got error value sometimes
<linus2>
the value too much different(too big or negtive) with using gettimeofday to calulate two postion's time spend in C
hpt has joined #systemtap
<linus2>
fche: what's your opinion?
<fche>
depending on kernel & runtime behaviour, gettimeofday_us may or may not be ideal; there are few synchronized high-res clocks in the system
<fche>
get_cycles() gives you a high resolution per-cpu counter; see if that hels
<linus2>
fche: get_cycles() get one cpu's cycle?
<fche>
get a cycle counter value from the invoking cpu
<fche>
so as long as you query again on the same cpu, you should generally get comparable & meaningful differences
<linus2>
why not using gettimeofday_us() to implement
<linus2>
If I using embedded C to call gettimeofday(), then the behavior is equal to call gettimeofday() in user code,right?
<fche>
gettimeofday_us is processed to some extent, or may delegate to a different kernel clock
<fche>
there are many
<fche>
nothing running in the kernel is equivalent to user code :-)
<linus2>
fche: what's the different
<fche>
everything
<linus2>
If using embedded C, it's very close to the user code,right?
<fche>
no, it's close to kernel code
<linus2>
so, how to close to the user code
<linus2>
like user code directing to call gettimeofday()
<fche>
you need to use a kernel-side timer that's approximately what you mean in userspace
<fche>
ktime_get_ns() may be a good choice
<linus2>
there are some missing
<linus2>
For example, xx.c:100 t1 = gettimeofday(), xx.c:200 t2 = gettimeofday(), delta = t2 -t1
<fche>
yes. so kernel clocks are not generally kept to the same high standard of synchronization / stability, because it's too costly & usually unnecessary
<linus2>
xx.stp embeded C delta = getttimeofday() - time_last
<linus2>
xx.stp embeded C delta1 = getttimeofday() - time_last
<fche>
there is no gettimeofday function in the kernel
<linus2>
I want to know whether delta1 close to the xx.c's delta
<fche>
try ktime_get_ns()
<linus2>
embeded C can only call kernel funciont,right?
<fche>
for normal stap operation modes, yes
<fche>
for stap --dyninst, embedded-C and everything is run/linked in userspace
<fche>
but that has other implications too
<linus2>
For example?
<linus2>
what's implication?
<fche>
dyninst is more invasive to the userspace program it is probing, and may cause some to malfunction, it's not ported to all architectures
<fche>
lots
<fche>
but feel free to try it.
<linus2>
it seems not well-used
<linus2>
If using embeded C and ktime_get_ns(), it will close to the xx.c's delta,right?
<linus2>
At present, the best way to get parallel region time
<fche>
suggest trying that
hpt has quit [Ping timeout: 256 seconds]
hpt has joined #systemtap
<linus2>
fche: thanks
orivej has quit [Ping timeout: 265 seconds]
<linus2>
fche: do you think it's better to optimize gettimeofday_us() for multithread program?