From: Alan Maguire <alan.maguire@oracle.com>
To: Chuyi Zhou <zhouchuyi@bytedance.com>,
hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
wuyun.abel@bytedance.com, robin.lu@bytedance.com
Subject: Re: [RFC PATCH 0/5] mm: Select victim memcg using BPF_OOM_POLICY
Date: Thu, 27 Jul 2023 12:43:58 +0100 [thread overview]
Message-ID: <7dbaabf9-c7c6-478b-0d07-b4ce0d7c116c@oracle.com> (raw)
In-Reply-To: <20230727073632.44983-1-zhouchuyi@bytedance.com>
On 27/07/2023 08:36, Chuyi Zhou wrote:
> This patchset tries to add a new bpf prog type and use it to select
> a victim memcg when global OOM is invoked. The mainly motivation is
> the need to customizable OOM victim selection functionality so that
> we can protect more important app from OOM killer.
>
It's a nice use case, but at a high level, the approach pursued here
is, as I understand it, discouraged for new BPF program development.
Specifically, adding a new BPF program type with semantics like this
is not preferred. Instead, can you look at using something like
- using "fmod_ret" instead of a new program type
- use BPF kfuncs instead of helpers.
- add selftests in tools/testing/selftests/bpf not samples.
There's some examples of how solutions have evolved from the traditional
approach (adding a new program type, helpers etc) to using kfuncs etc on
this list - for example HID-BPF and the BPF scheduler series - which
should help orient you. There are presentations from Linux Plumbers 2022
that walk through some of this too.
Judging by the sample program example, all you should need here is a way
to override the return value of bpf_oom_set_policy() - a noinline
function that by default returns a no-op. It can then be overridden by
an "fmod_ret" BPF program.
One thing you lose is cgroup specificity at BPF attach time, but you can
always add predicates based on the cgroup to your BPF program if needed.
Alan
> Chuyi Zhou (5):
> bpf: Introduce BPF_PROG_TYPE_OOM_POLICY
> mm: Select victim memcg using bpf prog
> libbpf, bpftool: Support BPF_PROG_TYPE_OOM_POLICY
> bpf: Add a new bpf helper to get cgroup ino
> bpf: Sample BPF program to set oom policy
>
> include/linux/bpf_oom.h | 22 ++++
> include/linux/bpf_types.h | 2 +
> include/linux/memcontrol.h | 6 ++
> include/uapi/linux/bpf.h | 21 ++++
> kernel/bpf/core.c | 1 +
> kernel/bpf/helpers.c | 17 +++
> kernel/bpf/syscall.c | 10 ++
> mm/memcontrol.c | 50 +++++++++
> mm/oom_kill.c | 185 +++++++++++++++++++++++++++++++++
> samples/bpf/Makefile | 3 +
> samples/bpf/oom_kern.c | 42 ++++++++
> samples/bpf/oom_user.c | 128 +++++++++++++++++++++++
> tools/bpf/bpftool/common.c | 1 +
> tools/include/uapi/linux/bpf.h | 21 ++++
> tools/lib/bpf/libbpf.c | 3 +
> tools/lib/bpf/libbpf_probes.c | 2 +
> 16 files changed, 514 insertions(+)
> create mode 100644 include/linux/bpf_oom.h
> create mode 100644 samples/bpf/oom_kern.c
> create mode 100644 samples/bpf/oom_user.c
>
next prev parent reply other threads:[~2023-07-27 11:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 7:36 Chuyi Zhou
2023-07-27 7:36 ` [RFC PATCH 1/5] bpf: Introduce BPF_PROG_TYPE_OOM_POLICY Chuyi Zhou
2023-07-27 7:36 ` [RFC PATCH 2/5] mm: Select victim memcg using bpf prog Chuyi Zhou
2023-07-27 7:36 ` [RFC PATCH 3/5] libbpf, bpftool: Support BPF_PROG_TYPE_OOM_POLICY Chuyi Zhou
2023-07-27 12:26 ` Quentin Monnet
2023-07-28 3:01 ` Chuyi Zhou
2023-07-27 7:36 ` [RFC PATCH 4/5] bpf: Add a new bpf helper to get cgroup ino Chuyi Zhou
2023-07-27 7:36 ` [RFC PATCH 5/5] bpf: Sample BPF program to set oom policy Chuyi Zhou
2023-07-27 8:15 ` [RFC PATCH 0/5] mm: Select victim memcg using BPF_OOM_POLICY Michal Hocko
2023-07-27 12:12 ` Chuyi Zhou
2023-07-27 17:23 ` Michal Hocko
2023-07-31 6:00 ` Chuyi Zhou
2023-07-31 13:23 ` Michal Hocko
2023-07-31 16:26 ` Chuyi Zhou
2023-08-01 8:18 ` Michal Hocko
2023-08-02 3:04 ` Chuyi Zhou
2023-07-28 4:30 ` Roman Gushchin
2023-07-28 8:06 ` Michal Hocko
2023-07-28 18:42 ` Roman Gushchin
2023-07-31 13:12 ` Michal Hocko
2023-08-01 6:53 ` Abel Wu
2023-07-27 11:43 ` Alan Maguire [this message]
2023-07-27 15:57 ` Alexei Starovoitov
2023-07-27 17:17 ` Michal Hocko
2023-07-28 2:34 ` [External] " Chuyi Zhou
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=7dbaabf9-c7c6-478b-0d07-b4ce0d7c116c@oracle.com \
--to=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=robin.lu@bytedance.com \
--cc=roman.gushchin@linux.dev \
--cc=wuyun.abel@bytedance.com \
--cc=zhouchuyi@bytedance.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
all inboxes | Powered by JetHome®