summaryrefslogtreecommitdiffstats
path: root/Documentation/bpf/verifier.rst
diff options
context:
space:
mode:
authorHao Luo <haoluo@google.com>2022-02-24 01:05:31 +0100
committerDaniel Borkmann <daniel@iogearbox.net>2022-02-28 18:10:28 +0100
commitceac059ed4fd8abc0940f799dd5133275011e244 (patch)
tree4e729eefc44be098eb1d1c0c3d21db73f8cb3658 /Documentation/bpf/verifier.rst
parentlibbpf: Fix BPF_MAP_TYPE_PERF_EVENT_ARRAY auto-pinning (diff)
downloadlinux-ceac059ed4fd8abc0940f799dd5133275011e244.tar.xz
linux-ceac059ed4fd8abc0940f799dd5133275011e244.zip
bpf: Cache the last valid build_id
For binaries that are statically linked, consecutive stack frames are likely to be in the same VMA and therefore have the same build id. On a real-world workload, we observed that 66% of CPU cycles in __bpf_get_stackid() were spent on build_id_parse() and find_vma(). As an optimization for this case, we can cache the previous frame's VMA, if the new frame has the same VMA as the previous one, reuse the previous one's build id. We are holding the MM locks as reader across the entire loop, so we don't need to worry about VMA going away. Tested through "stacktrace_build_id" and "stacktrace_build_id_nmi" in test_progs. Suggested-by: Greg Thelen <gthelen@google.com> Signed-off-by: Hao Luo <haoluo@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> Acked-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/bpf/20220224000531.1265030-1-haoluo@google.com
Diffstat (limited to 'Documentation/bpf/verifier.rst')
0 files changed, 0 insertions, 0 deletions