From: Roman Gushchin <roman.gushchin@linux.dev>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: linux-mm@kvack.org, bpf@vger.kernel.org,
Suren Baghdasaryan <surenb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.com>,
David Rientjes <rientjes@google.com>,
Matt Bobrowski <mattbobrowski@google.com>,
Song Liu <song@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 10/14] bpf: selftests: bpf OOM handler test
Date: Wed, 20 Aug 2025 15:49:53 -0700 [thread overview]
Message-ID: <878qjdobfy.fsf@linux.dev> (raw)
In-Reply-To: <CAP01T75_ArZiy9AB6TwNZCxKJKw+2yg58xz1ubTGZr4ynVt+Mg@mail.gmail.com> (Kumar Kartikeya Dwivedi's message of "Wed, 20 Aug 2025 11:33:42 +0200")
Kumar Kartikeya Dwivedi <memxor@gmail.com> writes:
> On Mon, 18 Aug 2025 at 19:02, Roman Gushchin <roman.gushchin@linux.dev> wrote:
>>
>> Implement a pseudo-realistic test for the OOM handling
>> functionality.
>>
>> The OOM handling policy which is implemented in bpf is to
>> kill all tasks belonging to the biggest leaf cgroup, which
>> doesn't contain unkillable tasks (tasks with oom_score_adj
>> set to -1000). Pagecache size is excluded from the accounting.
>>
>> The test creates a hierarchy of memory cgroups, causes an
>> OOM at the top level, checks that the expected process will be
>> killed and checks memcg's oom statistics.
>>
>> Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
>> ---
>> [...]
>> +
>> +/*
>> + * Find the largest leaf cgroup (ignoring page cache) without unkillable tasks
>> + * and kill all belonging tasks.
>> + */
>> +SEC("struct_ops.s/handle_out_of_memory")
>> +int BPF_PROG(test_out_of_memory, struct oom_control *oc)
>> +{
>> + struct task_struct *task;
>> + struct mem_cgroup *root_memcg = oc->memcg;
>> + struct mem_cgroup *memcg, *victim = NULL;
>> + struct cgroup_subsys_state *css_pos;
>> + unsigned long usage, max_usage = 0;
>> + unsigned long pagecache = 0;
>> + int ret = 0;
>> +
>> + if (root_memcg)
>> + root_memcg = bpf_get_mem_cgroup(&root_memcg->css);
>> + else
>> + root_memcg = bpf_get_root_mem_cgroup();
>> +
>> + if (!root_memcg)
>> + return 0;
>> +
>> + bpf_rcu_read_lock();
>> + bpf_for_each(css, css_pos, &root_memcg->css, BPF_CGROUP_ITER_DESCENDANTS_POST) {
>> + if (css_pos->cgroup->nr_descendants + css_pos->cgroup->nr_dying_descendants)
>> + continue;
>> +
>> + memcg = bpf_get_mem_cgroup(css_pos);
>> + if (!memcg)
>> + continue;
>> +
>> + usage = bpf_mem_cgroup_usage(memcg);
>> + pagecache = bpf_mem_cgroup_page_state(memcg, NR_FILE_PAGES);
>> +
>> + if (usage > pagecache)
>> + usage -= pagecache;
>> + else
>> + usage = 0;
>> +
>> + if ((usage > max_usage) && mem_cgroup_killable(memcg)) {
>> + max_usage = usage;
>> + if (victim)
>> + bpf_put_mem_cgroup(victim);
>> + victim = bpf_get_mem_cgroup(&memcg->css);
>> + }
>> +
>> + bpf_put_mem_cgroup(memcg);
>> + }
>> + bpf_rcu_read_unlock();
>> +
>> + if (!victim)
>> + goto exit;
>> +
>> + bpf_for_each(css_task, task, &victim->css, CSS_TASK_ITER_PROCS) {
>> + struct task_struct *t = bpf_task_acquire(task);
>> +
>> + if (t) {
>> + if (!bpf_task_is_oom_victim(task))
>> + bpf_oom_kill_process(oc, task, "bpf oom test");
>
> Is there a scenario where we want to invoke bpf_oom_kill_process when
> the task is not an oom victim?
Not really, but...
> Would it be better to subsume this check in the kfunc itself?
bpf_task_is_oom_victim() is useful by itself, because if we see
a task which is about to be killed, we can likely simple bail out.
Let me adjust the test to reflect it.
next prev parent reply other threads:[~2025-08-20 22:50 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 17:01 [PATCH v1 00/14] mm: BPF OOM Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 01/14] mm: introduce bpf struct ops for OOM handling Roman Gushchin
2025-08-19 4:09 ` Suren Baghdasaryan
2025-08-19 20:06 ` Roman Gushchin
2025-08-20 19:34 ` Suren Baghdasaryan
2025-08-20 19:52 ` Roman Gushchin
2025-08-20 20:01 ` Suren Baghdasaryan
2025-08-26 16:23 ` Amery Hung
2025-08-20 11:28 ` Kumar Kartikeya Dwivedi
2025-08-21 0:24 ` Roman Gushchin
2025-08-21 0:36 ` Kumar Kartikeya Dwivedi
2025-08-21 2:22 ` Roman Gushchin
2025-08-21 15:54 ` Suren Baghdasaryan
2025-08-22 19:27 ` Martin KaFai Lau
2025-08-25 17:00 ` Roman Gushchin
2025-08-26 18:01 ` Martin KaFai Lau
2025-08-26 19:52 ` Alexei Starovoitov
2025-08-27 18:28 ` Roman Gushchin
2025-09-02 17:31 ` Roman Gushchin
2025-09-02 22:30 ` Martin KaFai Lau
2025-09-02 23:36 ` Roman Gushchin
2025-09-03 0:29 ` Tejun Heo
2025-09-03 23:30 ` Roman Gushchin
2025-08-26 16:56 ` Amery Hung
2025-08-18 17:01 ` [PATCH v1 02/14] bpf: mark struct oom_control's memcg field as TRUSTED_OR_NULL Roman Gushchin
2025-08-20 9:17 ` Kumar Kartikeya Dwivedi
2025-08-20 22:32 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 03/14] mm: introduce bpf_oom_kill_process() bpf kfunc Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 04/14] mm: introduce bpf kfuncs to deal with memcg pointers Roman Gushchin
2025-08-20 9:21 ` Kumar Kartikeya Dwivedi
2025-08-20 22:43 ` Roman Gushchin
2025-08-20 23:33 ` Kumar Kartikeya Dwivedi
2025-08-18 17:01 ` [PATCH v1 05/14] mm: introduce bpf_get_root_mem_cgroup() bpf kfunc Roman Gushchin
2025-08-20 9:25 ` Kumar Kartikeya Dwivedi
2025-08-20 22:45 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 06/14] mm: introduce bpf_out_of_memory() " Roman Gushchin
2025-08-19 4:09 ` Suren Baghdasaryan
2025-08-19 20:16 ` Roman Gushchin
2025-08-20 9:34 ` Kumar Kartikeya Dwivedi
2025-08-20 22:59 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 07/14] mm: allow specifying custom oom constraint for bpf triggers Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 08/14] mm: introduce bpf_task_is_oom_victim() kfunc Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 09/14] bpf: selftests: introduce read_cgroup_file() helper Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 10/14] bpf: selftests: bpf OOM handler test Roman Gushchin
2025-08-20 9:33 ` Kumar Kartikeya Dwivedi
2025-08-20 22:49 ` Roman Gushchin [this message]
2025-08-20 20:23 ` Andrii Nakryiko
2025-08-21 0:10 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 11/14] sched: psi: refactor psi_trigger_create() Roman Gushchin
2025-08-19 4:09 ` Suren Baghdasaryan
2025-08-19 20:28 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 12/14] sched: psi: implement psi trigger handling using bpf Roman Gushchin
2025-08-19 4:11 ` Suren Baghdasaryan
2025-08-19 22:31 ` Roman Gushchin
2025-08-19 23:31 ` Roman Gushchin
2025-08-20 23:56 ` Suren Baghdasaryan
2025-08-26 17:03 ` Amery Hung
2025-08-18 17:01 ` [PATCH v1 13/14] sched: psi: implement bpf_psi_create_trigger() kfunc Roman Gushchin
2025-08-20 20:30 ` Andrii Nakryiko
2025-08-21 0:36 ` Roman Gushchin
2025-08-22 19:13 ` Andrii Nakryiko
2025-08-22 19:57 ` Martin KaFai Lau
2025-08-25 16:56 ` Roman Gushchin
2025-08-18 17:01 ` [PATCH v1 14/14] bpf: selftests: psi struct ops test Roman Gushchin
2025-08-19 4:08 ` [PATCH v1 00/14] mm: BPF OOM Suren Baghdasaryan
2025-08-19 19:52 ` Roman Gushchin
2025-08-20 21:06 ` Shakeel Butt
2025-08-21 0:01 ` Roman Gushchin
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=878qjdobfy.fsf@linux.dev \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mattbobrowski@google.com \
--cc=memxor@gmail.com \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
--cc=song@kernel.org \
--cc=surenb@google.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;
as well as URLs for NNTP newsgroup(s).