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,
quentin@isovalent.com, hannes@cmpxchg.org, mhocko@kernel.org,
roman.gushchin@linux.dev, shakeelb@google.com,
songmuchun@bytedance.com, akpm@linux-foundation.org,
cl@linux.com, penberg@kernel.org, rientjes@google.com,
iamjoonsoo.kim@lge.com, vbabka@suse.cz
Cc: linux-mm@kvack.org, bpf@vger.kernel.org,
Yafang Shao <laoar.shao@gmail.com>
Subject: [RFC PATCH bpf-next 02/10] bpftool: Show memcg info of bpf map
Date: Sun, 19 Jun 2022 15:50:24 +0000 [thread overview]
Message-ID: <20220619155032.32515-3-laoar.shao@gmail.com> (raw)
In-Reply-To: <20220619155032.32515-1-laoar.shao@gmail.com>
bpf map can be charged to a memcg, so we'd better show the memcg info to
do better bpf memory management. This patch adds a new field
"memcg_state" to show whether a bpf map is charged to a memcg and
whether the memcg is offlined. Currently it has three values,
0 : belongs to root memcg
-1 : its original memcg is not online now
1 : its original memcg is online
For instance,
$ bpftool map show
2: array name iterator.rodata flags 0x480
key 4B value 98B max_entries 1 memlock 4096B
btf_id 240 frozen
memcg_state 0
3: hash name calico_failsafe flags 0x1
key 4B value 1B max_entries 65535 memlock 524288B
memcg_state 1
6: lru_hash name access_record flags 0x0
key 8B value 24B max_entries 102400 memlock 3276800B
btf_id 256
memcg_state -1
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/uapi/linux/bpf.h | 4 +++-
kernel/bpf/syscall.c | 11 +++++++++++
tools/bpf/bpftool/map.c | 2 ++
tools/include/uapi/linux/bpf.h | 4 +++-
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index e81362891596..f2f658e224a7 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -6092,7 +6092,9 @@ struct bpf_map_info {
__u32 btf_id;
__u32 btf_key_type_id;
__u32 btf_value_type_id;
- __u32 :32; /* alignment pad */
+ __s8 memcg_state;
+ __s8 :8; /* alignment pad */
+ __u16 :16; /* alignment pad */
__u64 map_extra;
} __attribute__((aligned(8)));
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 7d5af5b99f0d..d4659d58d288 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -4168,6 +4168,17 @@ static int bpf_map_get_info_by_fd(struct file *file,
}
info.btf_vmlinux_value_type_id = map->btf_vmlinux_value_type_id;
+#ifdef CONFIG_MEMCG_KMEM
+ if (map->memcg) {
+ struct mem_cgroup *memcg = map->memcg;
+
+ if (memcg == root_mem_cgroup)
+ info.memcg_state = 0;
+ else
+ info.memcg_state = memcg_need_recharge(memcg) ? -1 : 1;
+ }
+#endif
+
if (bpf_map_is_dev_bound(map)) {
err = bpf_map_offload_info_fill(&info, map);
if (err)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 38b6bc9c26c3..ba68512e83aa 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -525,6 +525,7 @@ static int show_map_close_json(int fd, struct bpf_map_info *info)
jsonw_end_array(json_wtr);
}
+ jsonw_int_field(json_wtr, "memcg_state", info->memcg_state);
emit_obj_refs_json(refs_table, info->id, json_wtr);
jsonw_end_object(json_wtr);
@@ -615,6 +616,7 @@ static int show_map_close_plain(int fd, struct bpf_map_info *info)
if (frozen)
printf("%sfrozen", info->btf_id ? " " : "");
+ printf("\n\tmemcg_state %d", info->memcg_state);
emit_obj_refs_plain(refs_table, info->id, "\n\tpids ");
printf("\n");
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index e81362891596..f2f658e224a7 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -6092,7 +6092,9 @@ struct bpf_map_info {
__u32 btf_id;
__u32 btf_key_type_id;
__u32 btf_value_type_id;
- __u32 :32; /* alignment pad */
+ __s8 memcg_state;
+ __s8 :8; /* alignment pad */
+ __u16 :16; /* alignment pad */
__u64 map_extra;
} __attribute__((aligned(8)));
--
2.17.1
next prev parent reply other threads:[~2022-06-19 15:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-19 15:50 [RFC PATCH bpf-next 00/10] bpf, mm: Recharge pages when reuse " Yafang Shao
2022-06-19 15:50 ` [RFC PATCH bpf-next 01/10] mm, memcg: Add a new helper memcg_should_recharge() Yafang Shao
2022-06-19 15:50 ` Yafang Shao [this message]
2022-06-19 15:50 ` [RFC PATCH bpf-next 03/10] mm, memcg: Add new helper obj_cgroup_from_current() Yafang Shao
2022-06-23 3:01 ` Roman Gushchin
2022-06-25 13:54 ` Yafang Shao
2022-06-26 1:52 ` Roman Gushchin
2022-06-19 15:50 ` [RFC PATCH bpf-next 04/10] mm, memcg: Make obj_cgroup_{charge, uncharge}_pages public Yafang Shao
2022-06-19 15:50 ` [RFC PATCH bpf-next 05/10] mm: Add helper to recharge kmalloc'ed address Yafang Shao
2022-06-19 15:50 ` [RFC PATCH bpf-next 06/10] mm: Add helper to recharge vmalloc'ed address Yafang Shao
2022-06-19 15:50 ` [RFC PATCH bpf-next 07/10] mm: Add helper to recharge percpu address Yafang Shao
2022-06-23 5:25 ` Dennis Zhou
2022-06-25 14:18 ` Yafang Shao
2022-06-19 15:50 ` [RFC PATCH bpf-next 08/10] bpf: Recharge memory when reuse bpf map Yafang Shao
2022-06-19 15:50 ` [RFC PATCH bpf-next 09/10] bpf: Make bpf_map_{save, release}_memcg public Yafang Shao
2022-06-19 15:50 ` [RFC PATCH bpf-next 10/10] bpf: Support recharge for hash map Yafang Shao
2022-06-21 23:28 ` [RFC PATCH bpf-next 00/10] bpf, mm: Recharge pages when reuse bpf map Alexei Starovoitov
2022-06-22 14:03 ` Yafang Shao
2022-06-23 3:29 ` Roman Gushchin
2022-06-25 3:26 ` Yafang Shao
2022-06-26 3:28 ` Roman Gushchin
2022-06-26 3:32 ` Roman Gushchin
2022-06-26 6:38 ` Yafang Shao
2022-06-26 6:25 ` Yafang Shao
2022-07-02 4:23 ` Roman Gushchin
2022-07-02 15:24 ` Yafang Shao
2022-07-02 15:33 ` Roman Gushchin
2022-06-27 0:40 ` Alexei Starovoitov
2022-06-27 15:02 ` 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=20220619155032.32515-3-laoar.shao@gmail.com \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cl@linux.com \
--cc=daniel@iogearbox.net \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=quentin@isovalent.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=songliubraving@fb.com \
--cc=songmuchun@bytedance.com \
--cc=vbabka@suse.cz \
--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