linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org
Cc: linux-mm@kvack.org, rientjes@google.com, akpm@linux-foundation.org
Subject: Re: [PATCH] mm,oom: Re-enable OOM killer using timeout.
Date: Sun, 24 Apr 2016 23:19:03 +0900	[thread overview]
Message-ID: <201604242319.GAF12996.tOJMOQFLFVOHSF@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20160421130750.GA18427@dhcp22.suse.cz>

Michal Hocko wrote:
> I have seen that patch. I didn't get to review it properly yet as I am
> still travelling. From a quick view I think it is conflating two things
> together. I could see arguments for the panic part but I do not consider
> the move-to-kill-another timeout as justified. I would have to see a
> clear indication this is actually useful for real life usecases.

You admit that it is possible that the TIF_MEMDIE thread is blocked at
unkillable wait (due to memory allocation requests by somebody else) but
the OOM reaper cannot reap the victim's memory (due to holding the mmap_sem
for write), don't you?

Then, I think this patch makes little sense unless accompanied with the
move-to-kill-another timeout. If the OOM reaper failed to reap the victim's
memory, the OOM reaper simply clears TIF_MEMDIE from the victim thread. But
since nothing has changed (i.e. the victim continues waiting, and the victim's
memory is not reclaimed, and the victim's oom_score_adj is not updated to
OOM_SCORE_ADJ_MIN), the OOM killer will select that same victim again.
This forms an infinite loop. You will want to call panic() as soon as the OOM
reaper failed to reap the victim's memory (than waiting for the panic timeout).

For both system operators at customer's companies and staffs at support center,
avoiding hangup (due to OOM livelock) and panic (due to the OOM panic timeout)
eliminates a lot of overhead. This is a practical benefit for them.

I also think that the purpose of killing only one task at a time than calling
panic() is to save as much work as possible. Therefore, I can't understand why
you don't think that killing only another task via the move-to-kill-another
timeout is a useful real life usecase.

panic on timeout is a practical benefit for you, but giving several chances
on timeout is a practical benefit for someone you don't know.

--
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>

  reply	other threads:[~2016-04-24 14:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 15:06 Tetsuo Handa
2016-04-19 20:07 ` Michal Hocko
2016-04-19 21:55   ` Tetsuo Handa
2016-04-20 10:37     ` [PATCH v2] " Tetsuo Handa
2016-04-25 11:47       ` Michal Hocko
2016-04-26 14:00         ` Tetsuo Handa
2016-04-26 14:31           ` Michal Hocko
2016-04-27 10:43             ` Tetsuo Handa
2016-04-20 14:47     ` [PATCH] " Michal Hocko
2016-04-21 11:49       ` Tetsuo Handa
2016-04-21 13:07         ` Michal Hocko
2016-04-24 14:19           ` Tetsuo Handa [this message]
2016-04-25  9:55             ` Michal Hocko
2016-04-26 13:54               ` Michal Hocko
2016-04-27 10:43                 ` Tetsuo Handa
2016-04-27 11:11                   ` Michal Hocko
2016-05-14  0:39                     ` Tetsuo Handa
2016-05-16 14:18                       ` Michal Hocko
2016-05-17 11:08                         ` Tetsuo Handa
2016-05-17 12:51                           ` Michal Hocko
2016-04-26 14:00               ` Tetsuo Handa

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=201604242319.GAF12996.tOJMOQFLFVOHSF@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@kernel.org \
    --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