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]
<irker199>
systemtap: alizhang systemtap.git:azhang/pr13838 * release-4.3-96-gb4ab1f607 / testsuite/buildok/floatingpoint.stp: use try catch to handle NaN error
derek0883 has joined #systemtap
<kerneltoast>
fche okay I've run the testsuite and diffed the .sums
<kerneltoast>
so it strikes me as odd that these syscall failures are a surprise to you
<kerneltoast>
since i'm guessing you also use fedora
<kerneltoast>
unless you're really a secret bsd user
<fche>
kerneltoast, yeah it looks as though that sync syscall didn't show up in the second run
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
<fche>
there is sometimes some noise, with probes being missed for random momentary reasons
thibaultcha has quit [Client Quit]
<fche>
this test suite is picky for that
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
thibaultcha has quit [Client Quit]
<kerneltoast>
fche, picky as in it is trying to test for that, or it is just susceptible to random noise?
<fche>
picky in that it detects randomness well
<kerneltoast>
huh so i guess changes in code timing would influence that?
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
<fche>
conceivable ...
<fche>
but for that to be able to cause a missed probe, the change would not only have to slow things down (rather than improve), but slow things down a LOT, so stap or kernel side lock-timeouts are triggered
<kerneltoast>
hmm well the syscall failures have been consistently inconsistent across my testsuite runs
derek0883 has quit [Remote host closed the connection]
<kerneltoast>
some of them were failing before which are now passing
derek0883 has joined #systemtap
thibaultcha has quit [Client Quit]
<kerneltoast>
i could try an older, more well-known kernel
<fche>
nah it should be fine
<fche>
ok, if a lockdep kernel was happy, if there are no signs of memory leaks, go for it
<kerneltoast>
k i'll test lockdep and do some mem leak checking
<fche>
thansk
thibaultcha has joined #systemtap
thibaultcha has joined #systemtap
<kerneltoast>
i don't think agentzh would push this for at least a couple days
<kerneltoast>
since we need to do internal testing to see the performance improvement
<fche>
ok!
<kerneltoast>
maybe RCU is a scam and paul mckenney fooled us all
<fche>
not for the first time
<kerneltoast>
fche, speaking of which, there are some randomly strewn RCU read locks in stp_utrace.c that i don't quite understand the need for
<kerneltoast>
for example:
<kerneltoast>
rcu_read_lock();
<kerneltoast>
rcu_read_unlock();
<kerneltoast>
utrace->utrace_flags = flags;
<fche>
could be cargo-culting
<fche>
all hail st. mcpaul
<kerneltoast>
haha
<kerneltoast>
would you be opposed to a thorough rewrite of stp_utrace.c in the future?
<fche>
hmmmmmmmmm
<kerneltoast>
there's a lot of spaghetti in it
<kerneltoast>
and some marinara
<kerneltoast>
i wouldn't be doing this any time soon, but it'll be good to know whether or not you'd throw your computer at me for presenting you with such a thing
<fche>
well
<fche>
I wonder how much we need stp_utrace.c per se
<fche>
as opposed to having task_finder build on something closer to the kernel api
<kerneltoast>
oh that's a good point
orivej has joined #systemtap
irker199 has quit [Quit: transmission timeout]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
tonyj has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
amerey has quit [Remote host closed the connection]