Stating that spin locks are costly without empirical data seems premature. What's the scenario? What's the number of CPUs? What's the level of contention? Under light contention, spin locks in practic

<mayfieldtristan@...> wrote: BTW, everyone seems to be using -O2 for compiling BPF programs. Not sure how well-supported -O3 will be. [...] "classic BPF" is entirely different thing, don't use t

No, HASH_OF_MAPS allows arbitrary-sized keys, just like normal HASHMAP. Libbpf recently got a support for nicer map-in-map declaration and initialization, you might want to check it out: [0]. [0] http

#bcc

Hi! For the future, I think cc'ing bpf@... would be a good idea, there are a lot of folks who are probably not watching iovisor mailing list, but could help with issues like this. I'd star

You are not really accessing CPU registers, but you access their values before the program was interrupted. Those values are stored in pt_regs struct. It's a technicality in this case, but you can't a

adding back mailing list Notice offsets, they are all (except for first 4 fields which fit in first 8 bytes) 8-byte aligned. You can do that in your struct definitions as: int __syscall_nr __attribute

Just answered on another Github issue (https://github.com/iovisor/bcc/issues/2855#issuecomment-609532793), please check it there as well. Short answer: no. Unless you can pretty much guarantee that it

Yes. A lot of newer functionality relies on kernel BTF as well. But to compile portable BPF program you also need kernel BTF (for BPF CO-RE stuff). >

Take a closer look. libbpf-tools do not use bpf_load.h, that one is deprecated and its use is discouraged. libbpf-tools rely on code-generated BPF skeleton. But really, get a close look at libbpf-tool

Adding back mailing list. bpf_probe_read_str() has been there for a long time, at least 4.12 or even older. samples/bpf are part of kernel, so yes, they are using libbpf from kernel sources. For stand

nit: this is a legacy syntax of specifying BPF maps, please see [0] for some newer examples [0] https://github.com/iovisor/bcc/tree/master/libbpf-tools you don't need to bpf_probe_read() ctx here, you

Thanks! Glad it was useful. For kernel/libbpf development we do build Clang from sources, but you can install it from packages as well. See https://apt.llvm.org/, there are packages for Clang 10 and e

Have you looked at using libbpf and BPF CO-RE for such use cases? The difference is that you won't have any additional runtime dependencies (no Clang/LLVM, etc), which makes this more suitable for emb

<andrii.nakryiko=gmail.com@...> wrote: Discussion has been moved to https://github.com/iovisor/bcc/issues/2770 > > > > > > >

Hi! runqslower expects that kernel was built with BTF type info (which is enabled by CONFIG_DEBUG_INFO_BTF=y Kconfig option). Can you please re-build your kernel with BTF enabled and try again? > >