iovisor / iovisor/bcc

`kprobe` programs compared to `raw_tracepoint` programs for collecting syscall arguments

Open
#2,498 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
22.7k
Forks
4.1k
Avg merge
5d 13h
Merged PRs (30d)
3

Description

Hi, i'm new to ebpf. If we want to collect function arguments and return values of different syscall functions, we can use `kprobe`, `kretprobe` or `raw_tracepoint` type bpf programs. My understanding is, `raw_tracepoint` programs are faster because we can skip argument processing and get raw access to the arguments.

We can also collect these data using `kprobe` and `kretprobe`. My understanding is, these programs will be slower compared to `raw_tracepoint` programs as the are executed later in kernel and arguments are further processed.

My question is, even if we use `raw_tracepoint` programs, the kernel will eventually process the arguments and pass them to syscall functions, so `kprobe` programs should not be slower than `raw_tracepoint` programs. In this use case, for both type of programs, argument processing will be eventually done by kernel, so both type of programs should take same time, right?

Thanks!

Contributor guide

No contributing guide indexed for this repository

Research direction

The issue names kprobe, kretprobe, and raw_tracepoint programs but does not identify a file or test. Start by comparing their documented execution points and syscall argument handling in Linux and BCC; done would require a maintainer-backed explanation or a documentation update.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
observability, operating-systems
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.