summaryrefslogtreecommitdiff
path: root/arch/um
diff options
context:
space:
mode:
authorStanislav Fomichev <sdf@google.com>2021-01-15 08:35:00 -0800
committerAlexei Starovoitov <ast@kernel.org>2021-01-20 14:23:00 -0800
commit20f2505fb436cfa674cf1f46aaa624f44d3d1d03 (patch)
treeb23cdf6802d5b1f3952551c9648926450af095cd /arch/um
parent9cacf81f8161111db25f98e78a7a0e32ae142b3f (diff)
bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt
When we attach a bpf program to cgroup/getsockopt any other getsockopt() syscall starts incurring kzalloc/kfree cost. Let add a small buffer on the stack and use it for small (majority) {s,g}etsockopt values. The buffer is small enough to fit into the cache line and cover the majority of simple options (most of them are 4 byte ints). It seems natural to do the same for setsockopt, but it's a bit more involved when the BPF program modifies the data (where we have to kmalloc). The assumption is that for the majority of setsockopt calls (which are doing pure BPF options or apply policy) this will bring some benefit as well. Without this patch (we remove about 1% __kmalloc): 3.38% 0.07% tcp_mmap [kernel.kallsyms] [k] __cgroup_bpf_run_filter_getsockopt | --3.30%--__cgroup_bpf_run_filter_getsockopt | --0.81%--__kmalloc Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20210115163501.805133-3-sdf@google.com
Diffstat (limited to 'arch/um')
0 files changed, 0 insertions, 0 deletions