From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Michal Hocko <mhocko@kernel.org>
Cc: ytk.lee@samsung.com, "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
David Rientjes <rientjes@google.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm
Date: Tue, 9 Oct 2018 22:51:00 +0900 [thread overview]
Message-ID: <0ab96b81-042e-b9d9-8d63-b423941d8072@i-love.sakura.ne.jp> (raw)
In-Reply-To: <20181009132622.GR8528@dhcp22.suse.cz>
On 2018/10/09 22:26, Michal Hocko wrote:
> On Tue 09-10-18 22:14:24, Tetsuo Handa wrote:
>> On 2018/10/09 21:58, Michal Hocko wrote:
>>> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote:
>>>> On 2018/10/09 20:10, Michal Hocko wrote:
>>>>> On Tue 09-10-18 19:00:44, Tetsuo Handa wrote:
>>>>>>> 2) add OOM_SCORE_ADJ_MIN and do not kill tasks sharing mm and do not
>>>>>>> reap the mm in the rare case of the race.
>>>>>>
>>>>>> That is no problem. The mistake we made in 4.6 was that we updated oom_score_adj
>>>>>> to -1000 (and allowed unprivileged users to OOM-lockup the system).
>>>>>
>>>>> I do not follow.
>>>>>
>>>>
>>>> http://tomoyo.osdn.jp/cgi-bin/lxr/source/mm/oom_kill.c?v=linux-4.6.7#L493
>>>
>>> Ahh, so you are not referring to the current upstream code. Do you see
>>> any specific problem with the current one (well, except for the possible
>>> race which I have tried to evaluate).
>>>
>>
>> Yes. "task_will_free_mem(current) in out_of_memory() returns false due to MMF_OOM_SKIP
>> being already set" is a problem for clone(CLONE_VM without CLONE_THREAD/CLONE_SIGHAND)
>> with the current code.
>
> a) I fail to see how that is related to your previous post and b) could
> you be more specific. Is there any other scenario from the two described
> in my earlier email?
>
I do not follow. Just reverting commit 44a70adec910d692 and commit 97fd49c2355ffded
is sufficient for closing the copy_process() versus __set_oom_adj() race.
We went too far towards complete "struct mm_struct" based OOM handling. But stepping
back to "struct signal_struct" based OOM handling solves Yong-Taek's for_each_process()
latency problem and your copy_process() versus __set_oom_adj() race problem and my
task_will_free_mem(current) race problem.
next prev parent reply other threads:[~2018-10-09 13:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20181008011931epcms1p82dd01b7e5c067ea99946418bc97de46a@epcms1p8>
2018-10-08 1:19 ` [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm Yong-Taek Lee
2018-10-08 2:52 ` Tetsuo Handa
[not found] ` <CGME20181008011931epcms1p82dd01b7e5c067ea99946418bc97de46a@epcms1p5>
2018-10-08 6:14 ` Yong-Taek Lee
2018-10-08 6:22 ` Tetsuo Handa
[not found] ` <CGME20181008011931epcms1p82dd01b7e5c067ea99946418bc97de46a@epcms1p2>
2018-10-08 8:38 ` Yong-Taek Lee
2018-10-08 9:27 ` Tetsuo Handa
2018-10-09 6:35 ` Michal Hocko
2018-10-09 7:50 ` Michal Hocko
2018-10-09 10:00 ` Tetsuo Handa
2018-10-09 11:10 ` Michal Hocko
2018-10-09 12:52 ` Tetsuo Handa
2018-10-09 12:58 ` Michal Hocko
2018-10-09 13:14 ` Tetsuo Handa
2018-10-09 13:26 ` Michal Hocko
2018-10-09 13:51 ` Tetsuo Handa [this message]
2018-10-09 14:09 ` Michal Hocko
2018-10-09 8:02 ` Michal Hocko
[not found] <CGME20181005063208epcms1p22959cd2f771ad017996e2b18266791ea@epcms1p2>
[not found] ` <20181005063208epcms1p22959cd2f771ad017996e2b18266791ea@epcms1p2>
2018-10-09 6:23 ` Michal Hocko
2018-10-09 8:03 ` 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=0ab96b81-042e-b9d9-8d63-b423941d8072@i-love.sakura.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=oleg@redhat.com \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vdavydov.dev@gmail.com \
--cc=ytk.lee@samsung.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).