From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@suse.com
Cc: hannes@cmpxchg.org, akpm@linux-foundation.org,
linux-mm@kvack.org, aarcange@redhat.com,
mjaggi@caviumnetworks.com
Subject: Re: [PATCH 1/3] mm,oom: Move last second allocation to inside the OOM killer.
Date: Tue, 5 Dec 2017 23:07:53 +0900 [thread overview]
Message-ID: <201712052307.EEG40339.OFFJQMLOtHOFVS@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20171205134220.vwz5d23vtr3nocfs@dhcp22.suse.cz>
Michal Hocko wrote:
> On Tue 05-12-17 22:17:27, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > > I do understand the upsides you're advocating for - although you
> > > > haven't quantified them. They're just not worth the downsides.
> > >
> > > OK, fair enough. Let's drop the patch then. There is no _strong_
> > > justification for it and what I've seen as "nice to have" is indeed
> > > really hard to quantify and not really worth merging without a full
> > > consensus.
> >
> > Dropping "mm,oom: move last second allocation to inside the OOM killer"
> > means dropping "mm,oom: remove oom_lock serialization from the OOM reaper"
> > together, right?
>
> No, I believe that we can drop the lock even without this patch. This
> will need more investigation though.
We cannot drop the lock without this patch.
>
> > The latter patch helped mitigating
> > schedule_timeout_killable(1) lockup problem though...
> >
> > Also, what is the alternative for "mm,oom: use ALLOC_OOM for OOM victim's
> > last second allocation" ? I proposed "mm, oom: task_will_free_mem(current)
> > should ignore MMF_OOM_SKIP for once." and rejected by you. I also proposed
> > "mm,oom: Set ->signal->oom_mm to all thread groups sharing the victim's mm."
> > and rejected by you.
>
> Yes, and so far I am not really sure we have to care all that much. I
> haven't seen any real world workload actually hitting this condition.
>
Somebody will observe what Manish Jaggi observed. OOM with mlock()ed and/or
MAP_SHARED is irrelevant. There is always possibility that the OOM reaper
fails to reclaim memory due to mmap_sem contention (and results in extra
OOM kills).
--
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>
next prev parent reply other threads:[~2017-12-05 14:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-25 10:52 [PATCH 1/3] mm,oom: Move last second allocation to inside the OOM killer Tetsuo Handa
2017-11-25 10:52 ` [PATCH 2/3] mm,oom: Use ALLOC_OOM for OOM victim's last second allocation Tetsuo Handa
2017-11-25 10:52 ` [PATCH 3/3] mm,oom: Remove oom_lock serialization from the OOM reaper Tetsuo Handa
2017-11-28 13:04 ` [PATCH 1/3] mm,oom: Move last second allocation to inside the OOM killer Michal Hocko
2017-12-01 14:33 ` Johannes Weiner
2017-12-01 14:46 ` Michal Hocko
2017-12-01 14:56 ` Johannes Weiner
2017-12-01 15:17 ` Michal Hocko
2017-12-01 15:57 ` Johannes Weiner
2017-12-01 16:38 ` Michal Hocko
2017-12-05 10:46 ` Johannes Weiner
2017-12-05 13:02 ` Michal Hocko
2017-12-05 13:17 ` Tetsuo Handa
2017-12-05 13:42 ` Michal Hocko
2017-12-05 14:07 ` Tetsuo Handa [this message]
2017-12-05 14:30 ` Michal Hocko
2017-12-01 16:52 ` 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=201712052307.EEG40339.OFFJQMLOtHOFVS@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mjaggi@caviumnetworks.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.