linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: hannes@cmpxchg.org, akpm@linux-foundation.org,
	linux-mm@kvack.org, aarcange@redhat.com, rientjes@google.com,
	mjaggi@caviumnetworks.com, oleg@redhat.com,
	vdavydov.dev@gmail.com
Subject: Re: [PATCH] mm,oom: use ALLOC_OOM for OOM victim's last second allocation
Date: Mon, 11 Dec 2017 12:42:29 +0100	[thread overview]
Message-ID: <20171211114229.GA4779@dhcp22.suse.cz> (raw)
In-Reply-To: <201712081958.EBB43715.FOVJQFtFLOMOSH@I-love.SAKURA.ne.jp>

On Fri 08-12-17 19:58:11, Tetsuo Handa wrote:
[...]
> Therefore, I'm stuck between Michal and Johannes. And I updated "mm,oom: use
> ALLOC_OOM for OOM victim's last second allocation" not to depend on "mm,oom:
> move last second allocation to inside the OOM killer".

No, you seem to be stuck elsewhere. You keep ignoring that the OOM
killer is a best effort heuristic to free up some memory. And as any
other heuristic it has to balance cons and pros. One of the biggest
argument in those decision is how _serious_ the problem is another tweak
worth all the possible downfalls?

You keep repeating Manish report which is an _artificial_ OOM scenario.
It is true that we can do better in that case but the real solution
looks differently - we should make mlocked memory reapable. Now that is
not a trivial thing to do and I still have that on my todo list. You are
actively avoiding the real solution by providing tweaks (try one more
time) here and there. I really hate that approach. This will make the
behavior time dependant as Johannes pointed out.

I was OK with your "move the last allocation attempt" because it
conceptually makes some sense at least. Johannes had arguments against
and I do respect them because I do agree it is not a general and
_measurable_ win. And this is how the consensus based develoment works.
We are not pushing for questionable solutions unless there is an
absolute urge for that because the issue is serious and many users
suffer from it yet there is no real solution in sight. See the
difference?

That being said, I will keep refusing other such tweaks unless you have
a sound usecase behind. If you really _want_ to help out here then you
can focus on the reaping of the mlock memory.

Thanks
-- 
Michal Hocko
SUSE Labs

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

  parent reply	other threads:[~2017-12-11 11:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07 11:42 Tetsuo Handa
2017-12-07 11:51 ` Michal Hocko
2017-12-07 11:59   ` Tetsuo Handa
2017-12-07 12:22     ` Michal Hocko
2017-12-08 10:58       ` Tetsuo Handa
2017-12-11 11:15         ` [PATCH] mm, oom: task_will_free_mem() should ignore MMF_OOM_SKIP unless __GFP_NOFAIL Tetsuo Handa
2017-12-11 11:44           ` Michal Hocko
2017-12-11 11:42         ` Michal Hocko [this message]
2017-12-12  8:09           ` [PATCH] mm,oom: use ALLOC_OOM for OOM victim's last second allocation Tetsuo Handa
2017-12-12 10:07             ` Michal Hocko
2017-12-11 11:57 ` Michal Hocko
2017-12-13 11:06   ` Tetsuo Handa
2017-12-19 14:36     ` Tetsuo Handa
2017-12-19 14:55       ` Michal Hocko
2017-12-21 15:34         ` Tetsuo Handa
2017-12-21 16:42           ` Michal Hocko
2017-12-23 14:41             ` 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=20171211114229.GA4779@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mjaggi@caviumnetworks.com \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --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