fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
derek0883 has quit [Remote host closed the connection]
khaled_ has quit [Quit: Konversation terminated!]
derek0883 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
derek0883 has quit [Ping timeout: 246 seconds]
derek0883 has joined #systemtap
beauty2 has quit [Ping timeout: 246 seconds]
fdalleau_away has quit [Quit: Coyote finally caught me]
orivej 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
khaled has joined #systemtap
derek0883 has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
mjw has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
hpt has quit [Ping timeout: 264 seconds]
beauty2 has joined #systemtap
ggherdov has quit [Ping timeout: 246 seconds]
ggherdov has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 272 seconds]
amerey has joined #systemtap
derek0883 has joined #systemtap
fdalleau has joined #systemtap
fdalleau has quit [Quit: Coyote finally caught me]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
tromey has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
mjw has quit [Quit: Leaving]
<fche> https://bugzilla.redhat.com/show_bug.cgi?id=1914948 << hey dude, any suspicious why this would happen with the new transport but not the release-4.4 level one?
<kerneltoast> let's trade bugs
<kerneltoast> -DSTAP_TRANS_PROCFS makes the debugfs crash go away
<fche> noice
<kerneltoast> fche, it's probably a combination of _stp_subbuf_size being reduced in 8819e2a04596deb2fe427d261bebcaf3d2620dfb and _stp_data_write_reserve() needlessly burning through subbuffers
<kerneltoast> if you make a big request to _stp_data_write_reserve(), it'll pick out a subbuffer and then burn it if the requested alloc size won't fit in that subbuffer
<fche> that ruby test.sh case is minuscule tho,it prints like 7 lines
<kerneltoast> o
<kerneltoast> which commit does systemtap-4.4-6.el8 correspond to
<fche> it's not visible externally; it's a build of stap 4.4 plus all the runtime/transport-related patches over the last few months
<fche> (plus one or two other things)
<fche> (that should be irrelevant)
* fche hasn't reproduced the problem on git stap , just wanted to bring it to your attention
<kerneltoast> ah, but you can repro it just fine on that internal build?
<fche> our qa friend can apparently
<fche> so this was just reported to me a few hours back
<fche> Fresh News
<kerneltoast> did qa friend try git stap?
<fche> don't think so, mentioned it to him just now
<fche> hmmm
<fche> never ind about "small output"
<fche> it's 50000 lines in a few seconds
<fche> so yeah subbuf exhaustion etc. a possibility
<kerneltoast> actually i can make that conserve subbuffers even better
<kerneltoast> oh nvm i can't
<kerneltoast> or can it
<kerneltoast> *can i
<kerneltoast> fche, check this out: https://paste.centos.org/view/7e738827
<kerneltoast> might need tuning to make sure print buffers are flushed out when the module is unloaded
<fche> not sure we can just decrease the size_request like that - wouldnt' that cause cross-subbuf spans?
<kerneltoast> we already decrease the size request like that
<kerneltoast> size_request = __stp_relay_switch_subbuf(buf, size_request);
derek0883 has quit [Remote host closed the connection]
<kerneltoast> crossing subbufs is unavoidable
derek0883 has joined #systemtap
<kerneltoast> fche, so should we just roll with the procfs flag?
<fche> yeah I'm thinking we should just switch over
<fche> as the default
<kerneltoast> why are there two options anyway
<kerneltoast> someone can have debugfs disabled but good luck booting with procfs disabled
<fche> later
<fche> btw
<fche> stap -DDEBUG_TRANS for this test case shows a stream of len=78 / _stp_print_flush:30 prints
<fche> I wonder if we're wasting 8K (STP_BUFFER_SIZE) of content per each write
<fche> ok other data
<fche> with -DSTP_RELAY_TIMER_INTERVAL=1 we lose less data; with =0 we lose less yet, but still lose som
derek0883 has quit [Remote host closed the connection]
<kerneltoast> did you try my patch?
<fche> not yet, just gathering data
<kerneltoast> if you have thousands of small messages then i can see this happening
<kerneltoast> (without my patch)
<fche> yeah, that's what we're seeing.
derek0883 has joined #systemtap
orivej has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]