From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@suse.com, akpm@linux-foundation.org
Cc: linux-mm@kvack.org, rientjes@google.com,
mjaggi@caviumnetworks.com, oleg@redhat.com,
vdavydov.dev@gmail.com, torvalds@linux-foundation.org
Subject: Re: [PATCH] mm,oom: Warn on racing with MMF_OOM_SKIP at task_will_free_mem(current).
Date: Wed, 27 Sep 2017 14:00:14 +0900 [thread overview]
Message-ID: <201709271400.ICJ04687.FJVtHOSFFLQOOM@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20170926113951.g5dr4rplcbjjugno@dhcp22.suse.cz>
Michal Hocko wrote:
> On Tue 26-09-17 20:27:40, Tetsuo Handa wrote:
> [...]
> > @@ -794,8 +794,10 @@ static bool task_will_free_mem(struct task_struct *task)
> > * This task has already been drained by the oom reaper so there are
> > * only small chances it will free some more
> > */
> > - if (test_bit(MMF_OOM_SKIP, &mm->flags))
> > + if (test_bit(MMF_OOM_SKIP, &mm->flags)) {
> > + WARN(1, "Racing OOM victim selection. Please report to linux-mm@kvack.org if you saw this warning from non-artificial workloads.\n");
> > return false;
> > + }
>
> This can easily happen even without a race. Just consider that OOM
> memory reserves got depleted.
What!? You said test_bit(MMF_OOM_SKIP, &mm->flags) == T can easily happen?
I was assuming that you believe that test_bit(MMF_OOM_SKIP, &mm->flags) == T
can't easily happen.
ALLOC_OOM was introduced in order to prevent OOM memory reserves from getting
completely depleted. I assume that you meant that OOM memory reserves got low
enough to fail ALLOC_OOM allocation attempt. But at the same time it means that
there is possibility that OOM memory reserves are not low enough to fail
ALLOC_OOM allocation attempt (but !ALLOC_OOM allocation attempt fails) when
this happens. Then, we are sure that we are already killing next OOM victims
needlessly because there is possibility that ALLOC_OOM allocation attempt can
succeed if we force it by "mm, oom:task_will_free_mem(current) should ignore
MMF_OOM_SKIP for once." patch. You prove that there is no reason we defer that
patch. We can revert that patch when we find better implementation in the future.
> I think that the existing oom report will
> tell us that the race happened by checking the mm counters.
I don't think so. Normal users won't dare to post their OOM reports in
order to ask us to judge whether the race happened. We won't be able to
judge whether the race happened unless all OOM reports are unconditionally
posted to ML. What a horrible idea...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2017-09-27 5:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1506070646-4549-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
2017-09-25 14:30 ` [PATCH] [PATCH v3] mm, oom: task_will_free_mem(current) should ignore MMF_OOM_SKIP for once Michal Hocko
2017-09-25 15:09 ` Tetsuo Handa
2017-09-26 11:27 ` [PATCH] mm,oom: Warn on racing with MMF_OOM_SKIP at task_will_free_mem(current) Tetsuo Handa
2017-09-26 11:39 ` Michal Hocko
2017-09-27 5:00 ` Tetsuo Handa [this message]
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=201709271400.ICJ04687.FJVtHOSFFLQOOM@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mjaggi@caviumnetworks.com \
--cc=oleg@redhat.com \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vdavydov.dev@gmail.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