summaryrefslogtreecommitdiff
path: root/Documentation/bpf/verifier.rst
diff options
context:
space:
mode:
authorHao Luo <haoluo@google.com>2022-02-24 03:05:31 +0300
committerDaniel Borkmann <daniel@iogearbox.net>2022-02-28 20:10:28 +0300
commitceac059ed4fd8abc0940f799dd5133275011e244 (patch)
tree4e729eefc44be098eb1d1c0c3d21db73f8cb3658 /Documentation/bpf/verifier.rst
parenta4fbfdd7a160eccaafc093eb5b34f838b1ca0bf0 (diff)
downloadlinux-ceac059ed4fd8abc0940f799dd5133275011e244.tar.xz
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