You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support for CPU profiling, like "perf record -F 99 -a -g -- sleep 10". The advantage of bcc/eBPF is efficiency: stack traces can be frequency counted in kernel context (an eBPF map), and only the summary emitted to user level. The current operation of perf_events is to write a perf.data file with every stack sample, which involves extra CPU and file system overhead (context switches have been minimized thanks to perf's dynamic wakeups).
While this will be an everyday feature, I've put the priority as medium and not high because Linux perf_events is an adequate workaround for now.
The text was updated successfully, but these errors were encountered:
bpf program can kprobe into HZ tick, but there are NO_HZ environment, so need to be able to setup a timer fired BPF programs. Like generic sampling. Since such programs will likely access hw counters, need to make sure that it plays nice with NMI stuff.
For anyone looking up this ticket, while profile.py works (defaulting to a kprobe), it needs to be rewritten to use the upcoming perf_event_open() BPF support.
Support for CPU profiling, like "perf record -F 99 -a -g -- sleep 10". The advantage of bcc/eBPF is efficiency: stack traces can be frequency counted in kernel context (an eBPF map), and only the summary emitted to user level. The current operation of perf_events is to write a perf.data file with every stack sample, which involves extra CPU and file system overhead (context switches have been minimized thanks to perf's dynamic wakeups).
While this will be an everyday feature, I've put the priority as medium and not high because Linux perf_events is an adequate workaround for now.
The text was updated successfully, but these errors were encountered: