From: Yafang Shao <laoar.shao@gmail.com>
To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org, horenc@vt.edu,
xiyou.wangcong@gmail.com
Cc: bpf@vger.kernel.org, Yafang Shao <laoar.shao@gmail.com>
Subject: [PATCH bpf-next v2 00/18] bpf: bpf memory usage
Date: Wed, 22 Feb 2023 01:45:35 +0000 [thread overview]
Message-ID: <20230222014553.47744-1-laoar.shao@gmail.com> (raw)
Currently we can't get bpf memory usage reliably. bpftool now shows the
bpf memory footprint, which is difference with bpf memory usage. The
difference can be quite great in some cases, for example,
- non-preallocated bpf map
The non-preallocated bpf map memory usage is dynamically changed. The
allocated elements count can be from 0 to the max entries. But the
memory footprint in bpftool only shows a fixed number.
- bpf metadata consumes more memory than bpf element
In some corner cases, the bpf metadata can consumes a lot more memory
than bpf element consumes. For example, it can happen when the element
size is quite small.
- some maps don't have key, value or max_entries
For example the key_size and value_size of ringbuf is 0, so its
memlock is always 0.
We need a way to show the bpf memory usage especially there will be more
and more bpf programs running on the production environment and thus the
bpf memory usage is not trivial.
This patchset introduces a new map ops ->map_mem_usage to calculate the
memory usage. Note that we don't intend to make the memory usage 100%
accurate, while our goal is to make sure there is only a small difference
between what bpftool reports and the real memory. That small difference
can be ignored compared to the total usage. That is enough to monitor
the bpf memory usage. For example, the user can rely on this value to
monitor the trend of bpf memory usage, compare the difference in bpf
memory usage between different bpf program versions, figure out which
map consume large memory, and etc.
This patchset implements the bpf memory usage for all maps, and yet there's
still work to do. We don't want to introduce runtime overhead in the
element update and delete path, but we have to do it for some
non-preallocated maps,
- devmap, xskmap
When we update or delete an element, it will allocate or free memory.
In order to track this dynamic memory, we have to track the count in
element update and delete path.
- cpumap
The element size of each cpumap element is not determinated. If we
want to track the usage, we have to count the size of all elements in
the element update and delete path. So I just put it aside currently.
- local_storage, bpf_local_storage
When we attach or detach a cgroup, it will allocate or free memory. If
we want to track the dynamic memory, we also need to do something in
the update and delete path. So I just put it aside currently.
- offload map
The element update and delete of offload map is via the netdev dev_ops,
in which it may dynamically allocate or free memory, but this dynamic
memory isn't counted in offload map memory usage currently.
The result of each map can be found in the individual patch.
Changes:
v1->v2: calculate the memory usage within bpf (Alexei)
- [v1] bpf, mm: bpf memory usage
https://lwn.net/Articles/921991/
- [RFC PATCH v2] mm, bpf: Add BPF into /proc/meminfo
https://lwn.net/Articles/919848/
- [RFC PATCH v1] mm, bpf: Add BPF into /proc/meminfo
https://lwn.net/Articles/917647/
Yafang Shao (18):
bpf: add new map ops ->map_mem_usage
bpf: lpm_trie memory usage
bpf: hashtab memory usage
bpf: arraymap memory usage
bpf: stackmap memory usage
bpf: reuseport_array memory usage
bpf: ringbuf memory usage
bpf: bloom_filter memory usage
bpf: cpumap memory usage
bpf: devmap memory usage
bpf: queue_stack_maps memory usage
bpf: bpf_struct_ops memory usage
bpf: local_storage memory usage
bpf, net: bpf_local_storage memory usage
bpf, net: sock_map memory usage
bpf, net: xskmap memory usage
bpf: offload map memory usage
bpf: enforce all maps having memory usage callback
include/linux/bpf.h | 8 ++++++++
include/linux/bpf_local_storage.h | 1 +
include/net/xdp_sock.h | 1 +
kernel/bpf/arraymap.c | 28 +++++++++++++++++++++++++
kernel/bpf/bloom_filter.c | 12 +++++++++++
kernel/bpf/bpf_cgrp_storage.c | 1 +
kernel/bpf/bpf_inode_storage.c | 1 +
kernel/bpf/bpf_local_storage.c | 10 +++++++++
kernel/bpf/bpf_struct_ops.c | 16 +++++++++++++++
kernel/bpf/bpf_task_storage.c | 1 +
kernel/bpf/cpumap.c | 10 +++++++++
kernel/bpf/devmap.c | 26 +++++++++++++++++++++--
kernel/bpf/hashtab.c | 43 +++++++++++++++++++++++++++++++++++++++
kernel/bpf/local_storage.c | 7 +++++++
kernel/bpf/lpm_trie.c | 11 ++++++++++
kernel/bpf/offload.c | 6 ++++++
kernel/bpf/queue_stack_maps.c | 10 +++++++++
kernel/bpf/reuseport_array.c | 8 ++++++++
kernel/bpf/ringbuf.c | 19 +++++++++++++++++
kernel/bpf/stackmap.c | 14 +++++++++++++
kernel/bpf/syscall.c | 20 ++++++++----------
net/core/bpf_sk_storage.c | 1 +
net/core/sock_map.c | 20 ++++++++++++++++++
net/xdp/xskmap.c | 13 ++++++++++++
24 files changed, 273 insertions(+), 14 deletions(-)
--
1.8.3.1
next reply other threads:[~2023-02-22 1:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 1:45 Yafang Shao [this message]
2023-02-22 1:45 ` [PATCH bpf-next v2 01/18] bpf: add new map ops ->map_mem_usage Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 02/18] bpf: lpm_trie memory usage Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 03/18] bpf: hashtab " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 04/18] bpf: arraymap " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 05/18] bpf: stackmap " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 06/18] bpf: reuseport_array " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 07/18] bpf: ringbuf " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 08/18] bpf: bloom_filter " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 09/18] bpf: cpumap " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 10/18] bpf: devmap " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 11/18] bpf: queue_stack_maps " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 12/18] bpf: bpf_struct_ops " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 13/18] bpf: local_storage " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 14/18] bpf, net: bpf_local_storage " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 15/18] bpf, net: sock_map " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 16/18] bpf, net: xskmap " Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 17/18] bpf: offload map " Yafang Shao
2023-02-22 11:01 ` kernel test robot
2023-02-23 14:17 ` Yafang Shao
2023-02-22 1:45 ` [PATCH bpf-next v2 18/18] bpf: enforce all maps having memory usage callback Yafang Shao
2023-02-22 19:20 ` Alexei Starovoitov
2023-02-23 14:15 ` Yafang Shao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230222014553.47744-1-laoar.shao@gmail.com \
--to=laoar.shao@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=horenc@vt.edu \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=sdf@google.com \
--cc=songliubraving@fb.com \
--cc=xiyou.wangcong@gmail.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox