fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
derek088_ 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]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 265 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 265 seconds]
derek0883 has joined #systemtap
hpt has joined #systemtap
<kerneltoast>
fche, the more i grok through the code needed to make per-cpu timers, the more i think it's just too high in overhead
<fche>
I mean the patch I showed you last week, the one that saved jiffies_64 or something
<fche>
and conditionally called switch_subbuf
<fche>
that you didn't like because what if this or that
modem_ has quit [Read error: Connection reset by peer]
<fche>
hmmm why don't we put that into what's left of _print_flush() ? ie. called at the end of a probe handler, so it can't let little prints break up
modem has joined #systemtap
<fche>
ie., don't associate it with a commit (one print op) but with the flush (one probe handler execution)
<kerneltoast>
agentzh had that idea too
<kerneltoast>
flush for every probe handler
<fche>
well, that's what we've had there for years
<kerneltoast>
flush for every probe handler and wait for staprun to consume before proceeding?
<fche>
no, can't wait
<kerneltoast>
oh yeah
<kerneltoast>
tracepoints are evil
<kerneltoast>
almost forgot
fdalleau has quit [Quit: Coyote finally caught me]
fdalleau has joined #systemtap
gavinguo___ has quit [*.net *.split]
gavinguo___ has joined #systemtap
derek0883 has quit [Remote host closed the connection]
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]
derek0883 has joined #systemtap
fdalleau is now known as fdalleau_away
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
amerey has quit [Quit: Leaving]
orivej has quit [Ping timeout: 240 seconds]
khaled has quit [Quit: Konversation terminated!]
<kerneltoast>
fche, so i took the satanic approach
<kerneltoast>
at least the implementation is nice and clean
<fche>
doesn't it seem to require an explicit message of this sort, when there's that nice little read(2) coming up in just a second?
<fche>
doesn't it seem WEIRD to ...
<kerneltoast>
it's because relay controls the read()
<kerneltoast>
and we don't
<kerneltoast>
that's the whole crux of this problem
<fche>
We could intervene
<kerneltoast>
how
<fche>
it's just a file_operations* vtable
<kerneltoast>
h a c k y
<kerneltoast>
the function that makes all of this a PITA is relay_file_poll()
<kerneltoast>
if we could hijack relay_file_poll() then staprun wouldn't need that command, and we wouldn't need to have at least 1 subbuf switched to make relay wake up staprun
<kerneltoast>
all we'd need is to swap the current subbuf in relay_file_poll() if there's data in it
<kerneltoast>
but so hacky...
<fche>
what wakes up staprun, if not kernel-side subbuf switching right now?
<kerneltoast>
signals
<kerneltoast>
poll_wait(filp, &buf->read_wait, wait); <--- this is where staprun is waiting
<fche>
in the trickle-output case, what is waking it up
<fche>
timeout?
<kerneltoast>
yeah, but when there's a timeout there's no subbuf to read
<kerneltoast>
maybe in a few years you can get some intern to slave away and get rid of relay from stap