From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@suse.cz
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, oleg@redhat.com,
rientjes@google.com, vdavydov@parallels.com, mst@redhat.com
Subject: Re: [PATCH v3 0/8] Change OOM killer to use list of mm_struct.
Date: Tue, 26 Jul 2016 06:40:54 +0900 [thread overview]
Message-ID: <201607260640.CFJ12946.SMOFFQVHFJtLOO@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20160725141749.GI9401@dhcp22.suse.cz>
Michal Hocko wrote:
> On Mon 25-07-16 23:02:35, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Mon 25-07-16 20:47:03, Tetsuo Handa wrote:
> > > > Michal Hocko wrote:
> > > > > On Mon 25-07-16 20:07:11, Tetsuo Handa wrote:
> > > > > > Michal Hocko wrote:
> > > > > > > > Are you planning to change the scope where the OOM victims can access memory
> > > > > > > > reserves?
> > > > > > >
> > > > > > > Yes. Because we know that there are some post exit_mm allocations and I
> > > > > > > do not want to get back to PF_EXITING and other tricks...
> > > > > > >
> > > > > > > > (1) If you plan to allow the OOM victims to access memory reserves until
> > > > > > > > TASK_DEAD, tsk_is_oom_victim() will be as trivial as
> > > > > > > >
> > > > > > > > bool tsk_is_oom_victim(struct task_struct *task)
> > > > > > > > {
> > > > > > > > return task->signal->oom_mm;
> > > > > > > > }
> > > > > > >
> > > > > > > yes, exactly. That's what I've tried to say above. with the oom_mm this
> > > > > > > is trivial to implement while mm lists will not help us much due to
> > > > > > > their life time. This also means that we know about the oom victim until
> > > > > > > it is unhashed and become invisible to the oom killer.
> > > > > >
> > > > > > Then, what are advantages with allowing only OOM victims access to memory
> > > > > > reserves after they left exit_mm()?
> > > > >
> > > > > Because they might need it in order to move on... Say you want to close
> > > > > all the files which might release considerable amount of memory or any
> > > > > other post exit_mm() resources.
> > > >
> > > > OOM victims might need memory reserves in order to move on, but non OOM victims
> > > > might also need memory reserves in order to move on. And non OOM victims might
> > > > be blocking OOM victims via locks.
> > >
> > > Yes that might be true but OOM situations are rare events and quite
> > > reduced in the scope. Considering all exiting tasks is more dangerous
> > > because they might deplete those memory reserves easily.
> >
> > Why do you assume that we grant all of memory reserves?
>
> I've said deplete "those memory reserves". It would be just too easy to
> exit many tasks at once and use up that memory.
But that will not be a problem unless an OOM event occurs. Even if some
portion of memory reserves are granted, killed/exiting tasks unlikely
access memory reserves. If killed/exiting tasks need to deplete that
portion of memory reserves, it is reasonable to select an OOM victim.
>
> > I'm suggesting that we grant portion of memory reserves.
>
> Which doesn't solve anything because it will always be a finite resource
> which can get depleted. This is basically the same as the oom victim
> (ab)using reserves accept that OOM is much less likely and it is under
> control of the kernel which task gets killed.
Given that OOM is much less likely event, maybe we even do not need to use
task_struct->oom_reaper_list and instead we can use a global variable
static struct mm_struct *current_oom_mm;
and wait for current_oom_mm to become NULL regardless of in which domain an
OOM event occurred (as with we changed to use global oom_lock for preventing
concurrent OOM killer invocations)? Then, we can determine OOM_SCAN_ABORT by
inspecting that variable. This change may defer invocation of OOM killer in
different domains, but concurrent OOM events in different domains will be
also much less likely?
--
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:[~2016-07-25 21:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 13:29 [PATCH v3 0/8] Change OOM killer to use list of mm_struct Tetsuo Handa
2016-07-12 13:29 ` [PATCH 1/8] mm,oom_reaper: Reduce find_lock_task_mm() usage Tetsuo Handa
2016-07-12 13:29 ` [PATCH 2/8] mm,oom_reaper: Do not attempt to reap a task twice Tetsuo Handa
2016-07-12 14:19 ` Michal Hocko
2016-07-12 13:29 ` [PATCH 3/8] mm,oom: Use list of mm_struct used by OOM victims Tetsuo Handa
2016-07-12 14:28 ` Michal Hocko
2016-07-12 13:29 ` [PATCH 4/8] mm,oom: Close oom_has_pending_mm race Tetsuo Handa
2016-07-12 14:36 ` Michal Hocko
2016-07-12 13:29 ` [PATCH 5/8] mm,oom_reaper: Make OOM reaper use list of mm_struct Tetsuo Handa
2016-07-12 14:51 ` Michal Hocko
2016-07-12 15:42 ` Tetsuo Handa
2016-07-13 7:48 ` Michal Hocko
2016-07-12 13:29 ` [PATCH 6/8] mm,oom: Remove OOM_SCAN_ABORT case and signal_struct->oom_victims Tetsuo Handa
2016-07-12 13:29 ` [PATCH 7/8] mm,oom: Stop clearing TIF_MEMDIE on remote thread Tetsuo Handa
2016-07-12 14:53 ` Michal Hocko
2016-07-12 15:45 ` Tetsuo Handa
2016-07-13 8:13 ` Michal Hocko
2016-07-12 13:29 ` [PATCH 8/8] oom_reaper: Revert "oom_reaper: close race with exiting task" Tetsuo Handa
2016-07-12 14:56 ` Michal Hocko
2016-07-21 11:21 ` [PATCH v3 0/8] Change OOM killer to use list of mm_struct Michal Hocko
2016-07-22 11:09 ` Tetsuo Handa
2016-07-22 12:05 ` Michal Hocko
2016-07-23 2:59 ` Tetsuo Handa
2016-07-25 8:48 ` Michal Hocko
2016-07-25 11:07 ` Tetsuo Handa
2016-07-25 11:21 ` Michal Hocko
2016-07-25 11:47 ` Tetsuo Handa
2016-07-25 11:59 ` Michal Hocko
2016-07-25 14:02 ` Tetsuo Handa
2016-07-25 14:17 ` Michal Hocko
2016-07-25 21:40 ` Tetsuo Handa [this message]
2016-07-26 7:52 ` 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=201607260640.CFJ12946.SMOFFQVHFJtLOO@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.cz \
--cc=mst@redhat.com \
--cc=oleg@redhat.com \
--cc=rientjes@google.com \
--cc=vdavydov@parallels.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).