From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
Roman Gushchin <guro@fb.com>
Subject: Re: [PATCH v2] mm, oom: Fix unnecessary killing of additional processes.
Date: Mon, 10 Sep 2018 11:54:33 +0200 [thread overview]
Message-ID: <20180910095433.GE10951@dhcp22.suse.cz> (raw)
In-Reply-To: <1536382452-3443-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On Sat 08-09-18 13:54:12, Tetsuo Handa wrote:
[...]
I will not comment on the above because I have already done so and you
keep ignoring it so I will not waste my time again. But let me ask about
the following though
> This patch also fixes three possible bugs
>
> (1) oom_task_origin() tasks can be selected forever because it did not
> check for MMF_OOM_SKIP.
Is this a real problem. Could you point to any path that wouldn't bail
out and oom_origin task would keep trying for ever? If such a path
doesn't exist and you believe it is too fragile and point out the older
bugs proving that then I can imagine we should care.
> (2) sysctl_oom_kill_allocating_task path can be selected forever
> because it did not check for MMF_OOM_SKIP.
Why is that a problem? sysctl_oom_kill_allocating_task doesn't have any
well defined semantic. It is a gross hack to save long and expensive oom
victim selection. If we were too strict we should even not allow anybody
else but an allocating task to be killed. So selecting it multiple times
doesn't sound harmful to me.
> (3) CONFIG_MMU=n kernels might livelock because nobody except
> is_global_init() case in __oom_kill_process() sets MMF_OOM_SKIP.
And now the obligatory question. Is this a real problem?
> which prevent proof of "the forward progress guarantee"
> and adds one optimization
>
> (4) oom_evaluate_task() was calling oom_unkillable_task() twice because
> oom_evaluate_task() needs to check for !MMF_OOM_SKIP and
> oom_task_origin() tasks before calling oom_badness().
ENOPARSE
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-09-10 9:54 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-08 4:54 [PATCH v2] mm, oom: Fix unnecessary killing of additional processes Tetsuo Handa
2018-09-10 9:54 ` Michal Hocko [this message]
2018-09-10 11:27 ` Tetsuo Handa
2018-09-10 11:40 ` Michal Hocko
2018-09-10 12:52 ` Tetsuo Handa
2018-09-10 12:55 ` [RFC PATCH 0/3] rework mmap-exit vs. oom_reaper handover Michal Hocko
2018-09-10 12:55 ` [RFC PATCH 1/3] mm, oom: rework mmap_exit vs. oom_reaper synchronization Michal Hocko
2018-09-10 12:55 ` [RFC PATCH 2/3] mm, oom: keep retrying the oom_reap operation as long as there is substantial memory left Michal Hocko
2018-09-10 12:55 ` [RFC PATCH 3/3] mm, oom: hand over MMF_OOM_SKIP to exit path if it is guranteed to finish Michal Hocko
2018-09-10 14:59 ` [RFC PATCH 0/3] rework mmap-exit vs. oom_reaper handover Tetsuo Handa
2018-09-10 15:11 ` Michal Hocko
2018-09-10 15:40 ` Tetsuo Handa
2018-09-10 16:44 ` Michal Hocko
2018-09-12 3:06 ` Tetsuo Handa
2018-09-12 7:18 ` Michal Hocko
2018-09-12 7:58 ` Tetsuo Handa
2018-09-12 8:17 ` Michal Hocko
2018-09-12 10:59 ` Tetsuo Handa
2018-09-12 11:22 ` Michal Hocko
2018-09-11 14:01 ` Tetsuo Handa
2018-09-12 7:50 ` Michal Hocko
2018-09-12 13:42 ` Michal Hocko
2018-09-13 2:44 ` Tetsuo Handa
2018-09-13 9:09 ` Michal Hocko
2018-09-13 11:20 ` Tetsuo Handa
2018-09-13 11:35 ` Michal Hocko
2018-09-13 11:53 ` Tetsuo Handa
2018-09-13 13:40 ` Michal Hocko
2018-09-14 13:54 ` Tetsuo Handa
2018-09-14 14:14 ` Michal Hocko
2018-09-14 17:07 ` Tetsuo Handa
-- strict thread matches above, loose matches on Subject: below --
2018-05-24 21:22 [rfc patch] mm, oom: fix unnecessary killing of additional processes David Rientjes
2018-06-14 20:42 ` [patch] " David Rientjes
2018-06-19 0:27 ` Andrew Morton
2018-06-19 20:34 ` David Rientjes
2018-06-20 21:59 ` [patch v2] " David Rientjes
2018-06-21 10:58 ` kbuild test robot
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=20180910095433.GE10951@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rientjes@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).