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 joined #systemtap
khaled has quit [Quit: Konversation terminated!]
<agentzh>
kerneltoast: yeah, they are so popular, as before.
<agentzh>
i remember i had to monitor those sites so that i can catch one.
hpt has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
demon000_ has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
kerneltoast has quit [Quit: Adieu, mon capitaine!]
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
irker820 has quit [Quit: transmission timeout]
_whitelogger has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
_whitelogger has joined #systemtap
mjw has quit [Quit: Leaving]
derek0883 has quit [Remote host closed the connection]
khaled has joined #systemtap
kerneltoast has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
hpt has quit [Ping timeout: 265 seconds]
demon000_ has joined #systemtap
mjw has joined #systemtap
derek0883 has joined #systemtap
demon000_ has quit [Remote host closed the connection]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 256 seconds]
tromey has joined #systemtap
amerey has joined #systemtap
irker754 has joined #systemtap
<irker754>
systemtap: scox systemtap.git:master * release-4.4-30-gd235f70e0 / buildrun.cxx tapset/x86_64/registers.stp: Support pointer_arg in dyninst mode
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
<kerneltoast>
fche, build bots are happy with bulkmode stuff?
<fche>
kerneltoast, so it seems
orivej has joined #systemtap
<kerneltoast>
fche, tests aren't failing?
<fche>
not enough failure on the board so far
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
<fche>
kerneltoast, just wondering ........
<fche>
how come we still have some #ifdef STP_BULKMODE in runtime/transport/*?
<kerneltoast>
because we agreed that bulkmode would now represent merging the log files at the end rather than on the fly
<fche>
I'm playing with staprun for other reasons and am seeing things from git/master definitely not looking bulk-mode-y in terms of the number of relayfs traceN files being created
<fche>
unless with stap -b
<kerneltoast>
hmm
<fche>
can see it with stap --vp 00005 and see which trace$N files get successfully opened
<kerneltoast>
the remaining bulkmode ifdefs in the transport are for some var called is_global and for making the module tell userspace that -b is in use
<kerneltoast>
idk what the is_global stuff is
<kerneltoast>
it looked like a no-op to me so i ignored it
<kerneltoast>
uh oh, is_global isn't a no-op
<kerneltoast>
it's used inside kernel/relay.c
<kerneltoast>
uhhhohhhh
<kerneltoast>
the is_global stuff is causing the behavior you're seeing
<kerneltoast>
you say you have a son old enough to drive but i'm not sure you're old enough to have a son
<fche>
if you're thinking I'm jesus, I'm going to disappoint you
<kerneltoast>
no i think you're frank
<kerneltoast>
always down to earth
<kerneltoast>
a very frank guy
<irker754>
systemtap: sultan systemtap.git:master * release-4.4-31-g3abe2c40b / runtime/transport/debugfs.c runtime/transport/procfs.c: transport: set is_global to zero even when bulkmode is disabled
<kerneltoast>
you saw nothing
<kerneltoast>
there was no bug
<kerneltoast>
there is no war in ba sing se
<fche>
noice
<agentzh>
seems like we should wait a bit longer for the fche test before merging the latest master into our private branch :)
<agentzh>
or the "frank test"
<kerneltoast>
yeaaaaaaaah
wcohen is now known as wcohen|bike
<kerneltoast>
he's not the only one deserving of the brown paper bag it seems
<kerneltoast>
:)
<fche>
welll .....
<fche>
so it's not quite that simple
<fche>
um or maybe it is
<kerneltoast>
it should be
<kerneltoast>
i had everything else covered in my patch
<fche>
trying to eradicate all the STP_BULKMODE goo from the runtime but relay.c infers bulkmode-ness from a message
<kerneltoast>
you need the STP_BULKMODE in runtime/transport/control.c
<fche>
yeah adding comments etc. to that effect
derek0883 has quit [Remote host closed the connection]
<fche>
we're taking soem shortcuts in the new staprun with respect to non-bulkmod ehandling
<fche>
stap_merge* sort records across cpus by timetsamp or sequence number or something like that
<kerneltoast>
there's a new staprun?
<fche>
(in normal stap -b operation
<fche>
whereas current("new") staprun just races across the per-cpu trace files and dumps them as they come
<fche>
we are not preserving all the same guarantees I believe we did before
<fche>
now
<fche>
I don't really care :-) in that some of those guarantees were probably not really needed
<fche>
but worth being aware
<kerneltoast>
there's a decent guarantee since write() is atomic
<kerneltoast>
and since print_flush is called in sane places
<fche>
a scenario could be probes hitting cpu 0 then 1 then 0 , each probe printing one line , but userspace getting woken up in time only once per cpu
<kerneltoast>
that won't happen unless there's a flush
<fche>
and then the two 0-probe lines would be printed together, as opposed to interleaving 1's line
<kerneltoast>
i had to be a bit careful with sprinkling flushes everywhere
<kerneltoast>
because what you're mentioning did in fact become an issue
<kerneltoast>
so there's a *decent* guarantee in place now
derek0883 has joined #systemtap
<kerneltoast>
it's not rock solid but it's decent
<kerneltoast>
the real issue will arise when the print buffer becomes full mid-print
<kerneltoast>
and it'll have to be flushed
<kerneltoast>
in that case, the message can get fragmented
<kerneltoast>
but that's decently rare
<kerneltoast>
and we could even adjust for that in fact
<kerneltoast>
if you think it's a problem
<kerneltoast>
but other than that, prints will be ordered intra-cpu
<kerneltoast>
but not inter-cpu
<fche>
right, it's the inter-cpu ordering that stp_merge deals with
<kerneltoast>
maybe the bulkmode description should be updated btw
<kerneltoast>
it's pretty esoteric at the moment
derek0883 has quit [Remote host closed the connection]
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
wcohen|bike is now known as wcohen
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]