From: Michal Hocko <mhocko@suse.com>
To: zhongjinji@honor.com
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
rientjes@google.com, shakeel.butt@linux.dev, npache@redhat.com,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, peterz@infradead.org, dvhart@infradead.org,
dave@stgolabs.net, andrealmeid@igalia.com,
liam.howlett@oracle.com, liulu.liu@honor.com, feng.han@honor.com
Subject: Re: [PATCH v4 2/3] mm/oom_kill: Only delay OOM reaper for processes using robust futexes
Date: Sun, 17 Aug 2025 21:37:27 +0200 [thread overview]
Message-ID: <aKIvd4ZCdWUEpBT_@tiehlicka> (raw)
In-Reply-To: <20250814135555.17493-3-zhongjinji@honor.com>
On Thu 14-08-25 21:55:54, zhongjinji@honor.com wrote:
> From: zhongjinji <zhongjinji@honor.com>
>
> The OOM reaper can quickly reap a process's memory when the system encounters
> OOM, helping the system recover. Without the OOM reaper, if a process frozen
> by cgroup v1 is OOM killed, the victims' memory cannot be freed, and the
> system stays in a poor state. Even if the process is not frozen by cgroup v1,
> reaping victims' memory is still meaningful, because having one more process
> working speeds up memory release.
>
> When processes holding robust futexes are OOM killed but waiters on those
> futexes remain alive, the robust futexes might be reaped before
> futex_cleanup() runs. It would cause the waiters to block indefinitely.
> To prevent this issue, the OOM reaper's work is delayed by 2 seconds [1].
> The OOM reaper now rarely runs since many killed processes exit within 2
> seconds.
>
> Because robust futex users are few, it is unreasonable to delay OOM reap for
> all victims. For processes that do not hold robust futexes, the OOM reaper
> should not be delayed and for processes holding robust futexes, the OOM
> reaper must still be delayed to prevent the waiters to block indefinitely [1].
>
> Link: https://lore.kernel.org/all/20220414144042.677008-1-npache@redhat.com/T/#u [1]
What has happened to
https://lore.kernel.org/all/aJGiHyTXS_BqxoK2@tiehlicka/T/#u ?
Generally speaking it would be great to provide a link to previous
versions of the patchset. I do not see v3 in my inbox (which is quite
messy ATM so I might have easily missed it).
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2025-08-17 19:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 13:55 [PATCH v4 0/3] mm/oom_kill: Only delay OOM reaper for processes using robust futexes zhongjinji
2025-08-14 13:55 ` [PATCH v4 1/3] futex: Introduce function process_has_robust_futex() zhongjinji
2025-08-14 13:55 ` [PATCH v4 2/3] mm/oom_kill: Only delay OOM reaper for processes using robust futexes zhongjinji
2025-08-15 14:41 ` Lorenzo Stoakes
2025-08-18 14:14 ` zhongjinji
2025-08-17 19:37 ` Michal Hocko [this message]
2025-08-18 12:08 ` zhongjinji
2025-08-19 10:49 ` Michal Hocko
2025-08-20 2:53 ` Davidlohr Bueso
2025-08-21 18:13 ` Michal Hocko
2025-08-21 19:45 ` Davidlohr Bueso
2025-08-14 13:55 ` [PATCH v4 3/3] mm/oom_kill: Have the OOM reaper and exit_mmap() traverse the maple tree in opposite orders zhongjinji
2025-08-14 23:09 ` Andrew Morton
2025-08-15 16:32 ` zhongjinji
[not found] ` <1CAF2012-C9A4-44E1-BEB1-A1ECE0BC0C3E@gmail.com>
2025-08-15 17:53 ` gio
2025-08-15 14:29 ` Lorenzo Stoakes
2025-08-15 15:01 ` Lorenzo Stoakes
2025-08-15 17:37 ` zhongjinji
2025-08-19 15:18 ` zhongjinji
2025-08-21 9:32 ` Lorenzo Stoakes
2025-08-25 14:12 ` zhongjinji
2025-08-15 14:41 ` Liam R. Howlett
2025-08-15 16:05 ` Liam R. Howlett
2025-08-14 23:13 ` [PATCH v4 0/3] mm/oom_kill: Only delay OOM reaper for processes using robust futexes Andrew Morton
2025-08-15 17:06 ` zhongjinji
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=aKIvd4ZCdWUEpBT_@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@igalia.com \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=feng.han@honor.com \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liulu.liu@honor.com \
--cc=mingo@redhat.com \
--cc=npache@redhat.com \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=shakeel.butt@linux.dev \
--cc=tglx@linutronix.de \
--cc=zhongjinji@honor.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).