From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: zhongjinji <zhongjinji@honor.com>
Cc: mhocko@suse.com, rientjes@google.com, shakeel.butt@linux.dev,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
liam.howlett@oracle.com, liulu.liu@honor.com, feng.han@honor.com
Subject: Re: [PATCH v5 1/2] mm/oom_kill: Do not delay oom reaper when the victim is frozen
Date: Tue, 26 Aug 2025 13:43:05 +0100 [thread overview]
Message-ID: <af4edeaf-d3c9-46a9-a300-dbaf5936e7d6@lucifer.local> (raw)
In-Reply-To: <20250825133855.30229-2-zhongjinji@honor.com>
On Mon, Aug 25, 2025 at 09:38:54PM +0800, zhongjinji wrote:
> The OOM reaper can quickly reap a process's memory when the system
> encounters OOM, helping the system recover. If the victim process is
> frozen and cannot be unfrozen in time, the reaper delayed by two seconds
> will cause the system to fail to recover quickly from the OOM state.
Be good to reference the commit where this was introduced.
>
> When an OOM occurs, if the victim is not unfrozen, delaying the OOM reaper
> will keep the system in a bad state for two seconds. Before scheduling the
> oom_reaper task, check whether the victim is in a frozen state. If the
> victim is frozen, do not delay the OOM reaper.
>
> Signed-off-by: zhongjinji <zhongjinji@honor.com>
This is a lot better than the previous version, thanks! :)
> ---
> mm/oom_kill.c | 40 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 25923cfec9c6..4b4d73b1e00d 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -683,6 +683,41 @@ static void wake_oom_reaper(struct timer_list *timer)
> wake_up(&oom_reaper_wait);
> }
>
> +/*
> + * When the victim is frozen, the OOM reaper should not be delayed, because
> + * if the victim cannot be unfrozen promptly, it may block the system from
> + * quickly recovering from the OOM state.
> + */
You should put comments like this with each of the predicates, so e.g. this
comment should be above the frozen check, and then you should write equivalent
ones for the rest.
However, if Shakeel's correct, you can vastly simplify this further, so
obviously in that instance you can reduce to the single comment.
> +static bool should_delay_oom_reap(struct task_struct *tsk)
> +{
> + struct mm_struct *mm = tsk->mm;
> + struct task_struct *p;
> + bool ret;
> +
> + if (!mm)
> + return true;
> +
> + if (!frozen(tsk))
> + return true;
> +
> + if (atomic_read(&mm->mm_users) <= 1)
> + return false;
> +
> + rcu_read_lock();
> + for_each_process(p) {
> + if (!process_shares_mm(p, mm))
> + continue;
> + if (same_thread_group(tsk, p))
> + continue;
> + ret = !frozen(p);
> + if (ret)
> + break;
> + }
> + rcu_read_unlock();
This surely in any case must exist as a helper somehwere (bieng lazy + not
checking), seems a prime candidate for that if not.
> +
> + return ret;
> +}
> +
> /*
> * Give the OOM victim time to exit naturally before invoking the oom_reaping.
> * The timers timeout is arbitrary... the longer it is, the longer the worst
> @@ -694,13 +729,16 @@ static void wake_oom_reaper(struct timer_list *timer)
> #define OOM_REAPER_DELAY (2*HZ)
> static void queue_oom_reaper(struct task_struct *tsk)
> {
> + bool delay;
> +
> /* mm is already queued? */
> if (test_and_set_bit(MMF_OOM_REAP_QUEUED, &tsk->signal->oom_mm->flags))
> return;
>
> get_task_struct(tsk);
> + delay = should_delay_oom_reap(tsk);
> timer_setup(&tsk->oom_reaper_timer, wake_oom_reaper, 0);
> - tsk->oom_reaper_timer.expires = jiffies + OOM_REAPER_DELAY;
> + tsk->oom_reaper_timer.expires = jiffies + (delay ? OOM_REAPER_DELAY : 0);
I mean, unless there's some reason not to, why not simplify to:
task->oom_reaper_timer.expires = jiffies;
if (should_delay_oom_reap(tsk))
task->oom_reaper_timer.expires += OOM_REAPER_DELAY;
While super spells things out and avoids the other noise.
> add_timer(&tsk->oom_reaper_timer);
> }
>
> --
> 2.17.1
>
next prev parent reply other threads:[~2025-08-26 12:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 13:38 [PATCH v5 0/2] Do not delay oom reaper when the victim is frozen zhongjinji
2025-08-25 13:38 ` [PATCH v5 1/2] mm/oom_kill: " zhongjinji
2025-08-25 19:41 ` Shakeel Butt
2025-08-26 13:01 ` zhongjinji
2025-08-26 12:43 ` Lorenzo Stoakes [this message]
2025-08-27 12:08 ` Michal Hocko
2025-08-27 12:14 ` zhongjinji
2025-08-25 13:38 ` [PATCH v5 2/2] mm/oom_kill: Have the OOM reaper and exit_mmap() traverse the maple tree in opposite order zhongjinji
2025-08-26 12:53 ` Lorenzo Stoakes
2025-08-26 13:37 ` Liam R. Howlett
2025-08-26 13:50 ` Lorenzo Stoakes
2025-08-26 15:21 ` Liam R. Howlett
2025-08-26 22:26 ` Shakeel Butt
2025-08-27 4:12 ` Liam R. Howlett
2025-08-27 4:25 ` Liam R. Howlett
2025-08-27 9:55 ` zhongjinji
2025-08-27 15:57 ` Suren Baghdasaryan
2025-08-28 0:38 ` Liam R. Howlett
2025-08-29 7:11 ` Michal Hocko
2025-08-29 7:14 ` Michal Hocko
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=af4edeaf-d3c9-46a9-a300-dbaf5936e7d6@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=akpm@linux-foundation.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=mhocko@suse.com \
--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).