Currently, bpf program can already collect stack traces
when certain events happens (e.g., cache miss counter or
cpu clock counter overflows). These stack traces can be
used for performance analysis. For jitted programs, e.g.,
hhvm (jited php), it is very hard to get the true stack
trace in the bpf program due to jit complexity.
To resolve this issue, hhvm implements a signal handler,
e.g. for SIGALARM, and a set of program locations which
it can dump stack traces. When it receives a signal, it will
dump the stack in next such program location.
The following is the current way to handle this use case:
. profiler installs a bpf program and polls on a map.
When certain event happens, bpf program writes to a map.
. Once receiving the information from the map, the profiler
sends a signal to hhvm.
This method could have large delays and cause profiling
results skewed.
This patch implements bpf_send_signal() helper to send a signal to
hhvm in real time, resulting in intended stack traces.
The patch is sent out as RFC as (1). I have not found a simple
solution to return error code from irq_work, and (2). I would
like some general feedback about the approach.
Changelogs:
v1 -> v2:
. fixed a compilation error/warning (missing return value in one
error branch) discovered by kbuild bot.
Yonghong Song (3):
bpf: implement bpf_send_signal() helper
tools/bpf: sync bpf uapi header bpf.h
tools/bpf: add a selftest for bpf_send_signal() helper
include/uapi/linux/bpf.h | 15 +-
kernel/trace/bpf_trace.c | 85 ++++++++
tools/include/uapi/linux/bpf.h | 15 +-
tools/testing/selftests/bpf/Makefile | 5 +-
tools/testing/selftests/bpf/bpf_helpers.h | 2 +
.../bpf/progs/test_send_signal_kern.c | 50 +++++
.../selftests/bpf/test_send_signal_user.c | 186 ++++++++++++++++++
7 files changed, 354 insertions(+), 4 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_send_signal_kern.c
create mode 100644 tools/testing/selftests/bpf/test_send_signal_user.c
--
2.17.1
