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 joined #systemtap
orivej has quit [Ping timeout: 276 seconds]
zodbot has quit [Remote host closed the connection]
zodbot has joined #systemtap
mjw has quit [Quit: Leaving]
hpt has joined #systemtap
_whitelogger has joined #systemtap
_whitelogger 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: 240 seconds]
derek0883 has quit [Remote host closed the connection]
<kerneltoast>
lemme know if you think it can be split more
<fche>
reading
<kerneltoast>
I'll make the refcount patch's commit message nicer later
khaled has quit [Quit: Konversation terminated!]
<fche>
noting still some rcu usage, e.g. in utrace_exit()
<fche>
are those still needed?
<fche>
also, did you have a chance to run the normal stap testsuite also, or just your haircutter ?
<fche>
in utrace_finish_stop(), what's the purpose of lock then unlock of utrace->lock?
<fche>
meh, previous code does the same thing
derek088_ has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
<kerneltoast>
fche, yeah some locks can be trimmed i think, like in utrace cleanup since no more engines will be added
<kerneltoast>
i haven't run this on the normal testsuite
<kerneltoast>
I'll do that when i get back to muh laptop
<kerneltoast>
rcu is needed to iterate on the hashlist
<kerneltoast>
and i too have no idea what that lock/unlock is for
<fche>
guess it makes sure no one else had it, at least briefly
<kerneltoast>
it might not be needed with refcounts
<kerneltoast>
unless there's some synchronization requirement
amerey has quit [Quit: Leaving]
mjw has quit [Quit: Leaving]
lijunlong has quit [Read error: Connection reset by peer]
lijunlong has joined #systemtap
<kerneltoast>
okey back at laptop
<kerneltoast>
fche, the rcu read lock in utrace_exit() is probably not needed but i was paranoid
<kerneltoast>
i think the justification i gave myself was it's needed if a grace period hadn't elapsed between the time of the last utrace free and iterating through the hashlist in utrace_exit()
<kerneltoast>
oh yeah i kept the utrace->lock in utrace_cleanup() in case an engine could be in use while freeing the utrace struct
<kerneltoast>
if that's possible, then we need to listen to this comment: /* FIXME: hmm, should this be utrace_engine_put()? */