BPF List
 help / color / mirror / Atom feed
From: Yafang Shao <laoar.shao@gmail.com>
To: roman.gushchin@linux.dev, 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,
	shuah@kernel.org
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	Yafang Shao <laoar.shao@gmail.com>
Subject: [PATCH 01/14] bpf: Introduce no charge flag for bpf map
Date: Sat, 19 Mar 2022 17:30:23 +0000	[thread overview]
Message-ID: <20220319173036.23352-2-laoar.shao@gmail.com> (raw)
In-Reply-To: <20220319173036.23352-1-laoar.shao@gmail.com>

A new map flag BPF_F_NO_CHARGE is introduced in bpf_attr, with which we
can choose not to charge map memory while account it to root memcg only.
At the map creation time, we can get the no charge flag from struct
bpf_attr directly, while for other paths we can get it from struct
bpf_map.

The usecase of this flag is that sometimes we may create bpf maps with a
process running in a container (with memcg) but these maps are targeted
to the whole system, so we don't want to charge these memory into this
container. That will be good for memory resource management for this
container, as these shared bpf maps are always pinned which should
belong to the system rather than this container. That can also help
to make the charging behavior consistent, for example, if we charge the
pinned memory into this container, after the contianer restarts these
memory will not belong to it any more.

Two helpers are introduced for followup usage.

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
 include/linux/bpf.h            | 15 ++++++++++++++-
 include/uapi/linux/bpf.h       |  3 +++
 kernel/bpf/syscall.c           |  1 +
 tools/include/uapi/linux/bpf.h |  3 +++
 4 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 88449fbbe063..07c6603a6c81 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -184,7 +184,8 @@ struct bpf_map {
 	char name[BPF_OBJ_NAME_LEN];
 	bool bypass_spec_v1;
 	bool frozen; /* write-once; write-protected by freeze_mutex */
-	/* 14 bytes hole */
+	bool no_charge; /* Don't charge to memcg */
+	/* 13 bytes hole */
 
 	/* The 3rd and 4th cacheline with misc members to avoid false sharing
 	 * particularly with refcounting.
@@ -207,6 +208,18 @@ struct bpf_map {
 	} owner;
 };
 
+static inline gfp_t
+map_flags_no_charge(gfp_t flags, union bpf_attr *attr)
+{
+	return flags |= (attr->map_flags & BPF_F_NO_CHARGE) ? 0 : __GFP_ACCOUNT;
+}
+
+static inline gfp_t
+bpf_flags_no_charge(gfp_t flags, bool no_charge)
+{
+	return flags |= no_charge ? 0 : __GFP_ACCOUNT;
+}
+
 static inline bool map_value_has_spin_lock(const struct bpf_map *map)
 {
 	return map->spin_lock_off >= 0;
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 7604e7d5438f..e2dba6cdd88d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1225,6 +1225,9 @@ enum {
 
 /* Create a map that is suitable to be an inner map with dynamic max entries */
 	BPF_F_INNER_MAP		= (1U << 12),
+
+/* Don't charge memory to memcg */
+	BPF_F_NO_CHARGE		= (1U << 13),
 };
 
 /* Flags for BPF_PROG_QUERY. */
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index cdaa1152436a..029f04588b1a 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -368,6 +368,7 @@ void bpf_map_init_from_attr(struct bpf_map *map, union bpf_attr *attr)
 	map->map_flags = bpf_map_flags_retain_permanent(attr->map_flags);
 	map->numa_node = bpf_map_attr_numa_node(attr);
 	map->map_extra = attr->map_extra;
+	map->no_charge = attr->map_flags & BPF_F_NO_CHARGE;
 }
 
 static int bpf_map_alloc_id(struct bpf_map *map)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 7604e7d5438f..e2dba6cdd88d 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1225,6 +1225,9 @@ enum {
 
 /* Create a map that is suitable to be an inner map with dynamic max entries */
 	BPF_F_INNER_MAP		= (1U << 12),
+
+/* Don't charge memory to memcg */
+	BPF_F_NO_CHARGE		= (1U << 13),
 };
 
 /* Flags for BPF_PROG_QUERY. */
-- 
2.17.1


  reply	other threads:[~2022-03-19 17:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-19 17:30 [PATCH 00/14] bpf: Allow not to charge bpf memory Yafang Shao
2022-03-19 17:30 ` Yafang Shao [this message]
2022-03-19 17:30 ` [PATCH 02/14] bpf: Only sys admin can set no charge flag Yafang Shao
2022-03-19 17:30 ` [PATCH 03/14] bpf: Enable no charge in map _CREATE_FLAG_MASK Yafang Shao
2022-03-19 17:30 ` [PATCH 04/14] bpf: Introduce new parameter bpf_attr in bpf_map_area_alloc Yafang Shao
2022-03-19 17:30 ` [PATCH 05/14] bpf: Allow no charge " Yafang Shao
2022-03-19 17:30 ` [PATCH 06/14] bpf: Allow no charge for allocation not at map creation time Yafang Shao
2022-03-19 17:30 ` [PATCH 07/14] bpf: Allow no charge in map specific allocation Yafang Shao
2022-03-19 17:30 ` [PATCH 08/14] bpf: Aggregate flags for BPF_PROG_LOAD command Yafang Shao
2022-03-19 17:30 ` [PATCH 09/14] bpf: Add no charge flag for bpf prog Yafang Shao
2022-03-19 17:30 ` [PATCH 10/14] bpf: Only sys admin can set " Yafang Shao
2022-03-19 17:30 ` [PATCH 11/14] bpf: Set __GFP_ACCOUNT at the callsite of bpf_prog_alloc Yafang Shao
2022-03-19 17:30 ` [PATCH 12/14] bpf: Allow no charge for bpf prog Yafang Shao
2022-03-19 17:30 ` [PATCH 13/14] bpf: selftests: Add test case for BPF_F_NO_CHARTE Yafang Shao
2022-03-19 17:30 ` [PATCH 14/14] bpf: selftests: Add test case for BPF_F_PROG_NO_CHARGE Yafang Shao
2022-03-21 22:52 ` [PATCH 00/14] bpf: Allow not to charge bpf memory Roman Gushchin
2022-03-22 16:10   ` Yafang Shao
2022-03-22 19:10     ` Roman Gushchin
2022-03-23  1:37       ` 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=20220319173036.23352-2-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=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=roman.gushchin@linux.dev \
    --cc=shuah@kernel.org \
    --cc=songliubraving@fb.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