19:10 <agentzh> fche: yeah we have our own dsl-based test scaffold which even have a converter script to convert our tests to stap's tcl-based tests.

19:11 <fche> yeah, I remember a bit when you showed me dunno a year ago?

19:11 <agentzh> just in case fche says "will you add some tests to your commit?"

19:11 <agentzh> yeah, 2 years ago.

19:12 <agentzh> without that converter, i'd rather jump off the golden gate bridge :)

19:13 <fche> don't do it --- you missed being in the documentary about jumpers

19:14 <agentzh> lol

19:15 <fche> not that it's a joking matter I guess :|

19:15 <agentzh> well, writing a converter is way easier than jumping. so don't worry :))

19:16 <agentzh> besides, i need to get kerneltoast and cosmin to write a lot more stap patches before i die :)

19:18 <agentzh> oh btw, we're thinking about patching the kernel to lift the ebpf verifier limits so that we can run more complex bpf programs.

19:18 <agentzh> maybe through a red hat kpatch ko.

19:18 <agentzh> that should get us a long way.

19:18 <agentzh> if it went well.

19:18 <agentzh> *goes

19:19 <agentzh> have you guys ever considered that?

19:19 <fche> hm, too bad some of those limits are compiled in -- otherwise could lift them with a stap script modifying the @var()'s

19:19 <agentzh> hah, fche is indeed more evil :)

19:21 <agentzh> ebpf is beautiful in that one does not have to invoke the full kernel build system to compile a kernel module.

19:21 <agentzh> it helps speeding up stap script development.

19:21 <agentzh> it's human time we're saving.

19:22 <agentzh> the iteration cycles can be very short.

19:22 <agentzh> even on moderate hardware.

19:23 <fche> hm, small scripts can take only a second or two to compile even with the normal backend

19:23 <fche> it all depends

19:23 <agentzh> so i'm all for lifting any ebpf restrictions.

19:23 <agentzh> sadly we're writing huge stap scripts.

19:23 <agentzh> small scripts are only for demonstrating stap bugs for us usually :)

19:26 <agentzh> fche: a stap hello world oneliner takes 3.29s in total on my fastest machine (core i9-9900k) while the bpf runtime of stap takes only 0.164s: https://gist.github.com/agentzh/1b2cb8be32426d101addc7ef489e7bcf

19:27 <agentzh> BIG difference.

19:27 <agentzh> consider that if i have hundreds if not thousands of such short stap scripts to regress in a test suite.

19:29 <agentzh> the kernel runtime is a must-have for older kernels since ebpf is still very young.

19:30 <agentzh> and we can also compare the same stap scripts against 2 runtimes just in case there a bug in one of the runtimes.

19:30 <agentzh> *there is

19:30 <agentzh> it's always good to have an alternative implementation.

19:31 <agentzh> (to compare things)

19:33 <agentzh> serhei: i have a concern that stap's bpf emiter may not generate bpf code as good as llvm's due to the lack of sophisticated optimizations. or am i wrong about this?

19:34 <agentzh> currently the kernel module C code emitted by stap's translator is not easier for gcc to optiimze due to the exessive use of struct field pointers allocated out of the stack or registers.

19:34 <agentzh> *not easy

19:35 <agentzh> and we definitely hope the in-kernel code can always run at extreme speed.

19:36 <agentzh> since a probe lock is held anyway.

19:36 <agentzh> and it may also run in an interrupt handler.

19:36 <fche> you know about the lock pushdown machinery, right? it makes holding those locks as brief as possible

19:37 <fche> anyway see stap -t for benchmarking the normal runtime versino

19:37 <agentzh> even when accessing a global?

19:37 <fche> yes

19:37 <agentzh> that's cool.

19:37 <fche> well, compare stap 4.3 and 4.4 (or git/master) to where/when the lock/unlock stuff is done, for different stap scripts

19:38 <agentzh> yeah, will give it a shot. thanks

20:43 <irker525> systemtap: smakarov systemtap.git:master * release-4.4-39-gdaaa9497e / bpf-base.cxx bpf-internal.h bpf-opt.cxx bpf-translate.cxx: stapbpf (for PR27030) tentative regalloc fix: zero unused regs