linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	cgroups@vger.kernel.org
Subject: Re: [patch] mm, memcg: add oom killer delay
Date: Sat, 1 Jun 2013 11:15:37 -0400	[thread overview]
Message-ID: <20130601151537.GD15576@cmpxchg.org> (raw)
In-Reply-To: <20130601102905.GB19474@dhcp22.suse.cz>

On Sat, Jun 01, 2013 at 12:29:05PM +0200, Michal Hocko wrote:
> On Sat 01-06-13 02:11:51, Johannes Weiner wrote:
> [...]
> > I'm currently messing around with the below patch.  When a task faults
> > and charges under OOM, the memcg is remembered in the task struct and
> > then made to sleep on the memcg's OOM waitqueue only after unwinding
> > the page fault stack.  With the kernel OOM killer disabled, all tasks
> > in the OOMing group sit nicely in
> > 
> >   mem_cgroup_oom_synchronize
> >   pagefault_out_of_memory
> >   mm_fault_error
> >   __do_page_fault
> >   page_fault
> >   0xffffffffffffffff
> > 
> > regardless of whether they were faulting anon or file.  They do not
> > even hold the mmap_sem anymore at this point.
> > 
> > [ I kept syscalls really simple for now and just have them return
> >   -ENOMEM, never trap them at all (just like the global OOM case).
> >   It would be more work to have them wait from a flatter stack too,
> >   but it should be doable if necessary. ]
> > 
> > I suggested this at the MM summit and people were essentially asking
> > if I was feeling well, so maybe I'm still missing a gaping hole in
> > this idea.
> 
> I didn't get to look at the patch (will do on Monday) but it doesn't
> sounds entirely crazy. Well, we would have to drop mmap_sem so things
> have to be rechecked but we are doing that already with VM_FAULT_RETRY
> in some archs so it should work.

The global OOM case has been doing this for a long time (1c0fe6e mm:
invoke oom-killer from page fault), way before VM_FAULT_RETRY.  The
fault is aborted with VM_FAULT_OOM and the oom killer is invoked.
Either the task gets killed or it'll just retrigger the fault.  The
only difference is that a memcg OOM kill may take longer because of
userspace handling, so memcg needs a waitqueue where the global case
simply does a trylock (try_set_zonelist_oom) and restarts the fault
immediately if somebody else is handling the situation.

In fact, when Nick added the page fault OOM invocation, KAME merged
something similar to my patch, which tried to catch memcg OOM kills
from pagefault_out_of_memory() (a636b32 memcg: avoid unnecessary
system-wide-oom-killer).

Only when he reworked the whole memcg OOM synchronization, added the
ability to disable OOM and the waitqueues etc, the OOMs were trapped
right there in the charge context (867578c memcg: fix oom kill
behavior).  But I see no reason why we shouldn't be able to keep the
waitqueues and still go back to synchronizing from the bottom of the
page fault stack.

--
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:[~2013-06-01 15:15 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30  1:18 David Rientjes
2013-05-30 15:07 ` Michal Hocko
2013-05-30 20:47   ` David Rientjes
2013-05-31  8:10     ` Michal Hocko
2013-05-31 10:22       ` David Rientjes
2013-05-31 11:02         ` Michal Hocko
2013-05-31 11:21         ` Michal Hocko
2013-05-31 19:29           ` David Rientjes
2013-06-01  6:11             ` Johannes Weiner
2013-06-01 10:29               ` Michal Hocko
2013-06-01 15:15                 ` Johannes Weiner [this message]
2013-06-03 15:34               ` Michal Hocko
2013-06-03 16:48                 ` Johannes Weiner
2013-06-03 18:03                   ` Michal Hocko
2013-06-03 18:30                   ` Johannes Weiner
2013-06-03 21:33                     ` KOSAKI Motohiro
2013-06-04  9:17                     ` Michal Hocko
2013-06-04 18:48                       ` Johannes Weiner
2013-06-04 19:27                         ` Michal Hocko
2013-06-05 13:49                         ` Michal Hocko
2013-06-03 16:31               ` Michal Hocko
2013-06-03 16:51                 ` Johannes Weiner
2013-06-01 10:20             ` Michal Hocko
2013-06-03 18:18               ` David Rientjes
2013-06-03 18:54                 ` Johannes Weiner
2013-06-03 19:09                   ` David Rientjes
2013-06-03 21:43                     ` Johannes Weiner
2013-06-03 19:31                 ` Michal Hocko
2013-06-03 21:17                   ` David Rientjes
2013-06-04  9:55                     ` Michal Hocko
2013-06-05  6:40                       ` David Rientjes
2013-06-05  9:39                         ` Michal Hocko
2013-06-06  0:09                           ` David Rientjes
2013-06-10 14:23                             ` Michal Hocko
2013-06-11 20:33                               ` David Rientjes
2013-06-12 20:23                                 ` Michal Hocko
2013-06-12 21:27                                   ` David Rientjes
2013-06-13 15:16                                     ` Michal Hocko
2013-06-13 22:25                                       ` David Rientjes
2013-06-14  0:56                                         ` Kamezawa Hiroyuki
2013-06-14 10:12                                           ` David Rientjes
2013-06-19 21:30                                             ` David Rientjes
2013-06-25  1:39                                             ` Kamezawa Hiroyuki
2013-06-26 23:18                                               ` David Rientjes
2013-07-10 11:23                                             ` Michal Hocko
2013-05-31 21:46 ` Andrew Morton
2013-06-03 18:00   ` David Rientjes

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=20130601151537.GD15576@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --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