linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	linux-mm@kvack.org
Subject: Re: [patch] memcg: add oom killer delay
Date: Mon, 7 Mar 2011 17:02:36 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1103071657090.24549@chino.kir.corp.google.com> (raw)
In-Reply-To: <20110307165119.436f5d21.akpm@linux-foundation.org>

On Mon, 7 Mar 2011, Andrew Morton wrote:

> > > > So the question I'd ask is
> > > 
> > > What about my question?  Why is your usersapce oom-handler "unresponsive"?
> > > 
> > 
> > If we have a per-memcg userspace oom handler, then it's absolutely 
> > required that it either increase the hard limit of the oom memcg or kill a 
> > task to free memory; anything else risks livelocking that memcg.  At 
> > the same time, the oom handler's memcg isn't really important: it may be 
> > in a different memcg but it may be oom at the same time.  If we risk 
> > livelocking the memcg when it is oom and the oom killer cannot respond 
> > (the only reason for the oom killer to exist in the first place), then 
> > there's no guarantee that a userspace oom handler could respond under 
> > livelock.
> 
> So you're saying that your userspace oom-handler is in a memcg which is
> also oom?

It could be, if users assign the handler to a different memcg; otherwise, 
it's guaranteed.  Keep in mind that for oom situations we give the killed 
task access to memory reserves below the min watermark with TIF_MEMDIE so 
that they can allocate memory to exit as quickly as possible (either to 
handle the SIGKILL or within the exit path).  That's because we can't 
guarantee anything within an oom system, cpuset, mempolicy, or memcg is 
ever responsive without it.  (And, the side effect of it and its threads 
exiting is the freeing of memory which allows everything else to once 
again be responsive.)

> That this is the only situation you've observed in which the
> userspace oom-handler is "unresponsive"?
> 

Personally, yes, but I could imagine other users could get caught if their 
userspace oom handler requires taking locks (such as mmap_sem) by reading 
within procfs that a thread within an oom memcg already holds.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-03-08  1:02 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-08  0:24 David Rientjes
2011-02-08  1:55 ` KAMEZAWA Hiroyuki
2011-02-08  2:13   ` David Rientjes
2011-02-08  2:13     ` KAMEZAWA Hiroyuki
2011-02-08  2:20       ` KAMEZAWA Hiroyuki
2011-02-08  2:37         ` David Rientjes
2011-02-08 10:25           ` Balbir Singh
2011-02-09 22:19 ` David Rientjes
2011-02-10  0:04   ` KAMEZAWA Hiroyuki
2011-02-16  3:15     ` David Rientjes
2011-02-20 22:19       ` David Rientjes
2011-02-23 23:08   ` Andrew Morton
2011-02-24  0:13     ` KAMEZAWA Hiroyuki
2011-02-24  0:51     ` David Rientjes
2011-03-03 20:11       ` David Rientjes
2011-03-03 21:52       ` Andrew Morton
2011-03-08  0:12         ` David Rientjes
2011-03-08  0:29           ` Andrew Morton
2011-03-08  0:36             ` David Rientjes
2011-03-08  0:51               ` Andrew Morton
2011-03-08  1:02                 ` David Rientjes [this message]
2011-03-08  1:18                   ` Andrew Morton
2011-03-08  1:33                     ` David Rientjes
2011-03-08  2:51                       ` KAMEZAWA Hiroyuki
2011-03-08  3:07                         ` David Rientjes
2011-03-08  3:13                           ` KAMEZAWA Hiroyuki
2011-03-08  3:56                             ` David Rientjes
2011-03-08  4:17                               ` KAMEZAWA Hiroyuki
2011-03-08  5:30                                 ` David Rientjes
2011-03-08  5:49                                   ` KAMEZAWA Hiroyuki
2011-03-08 23:49                                     ` David Rientjes
2011-03-09  6:04                                       ` KAMEZAWA Hiroyuki
2011-03-09  6:44                                         ` David Rientjes
2011-03-09  7:16                                           ` KAMEZAWA Hiroyuki
2011-03-09 21:12                                             ` David Rientjes
2011-03-09 21:27                                               ` [patch] memcg: give current access to memory reserves if it's trying to die David Rientjes
2011-03-09 23:30                                                 ` KAMEZAWA Hiroyuki
2011-03-17 23:37                                                   ` David Rientjes
2011-03-17 23:53                                                 ` Andrew Morton
2011-03-18  4:35                                                   ` KAMEZAWA Hiroyuki
2011-03-18  5:17                                                     ` Andrew Morton
2011-03-18  5:58                                                       ` KAMEZAWA Hiroyuki
2011-03-18 20:36                                                       ` David Rientjes
2011-03-18 20:32                                                   ` David Rientjes
2011-03-08  3:06                     ` [patch] memcg: add oom killer delay KAMEZAWA Hiroyuki
  -- strict thread matches above, loose matches on Subject: below --
2010-12-22  7:27 David Rientjes
2010-12-22  7:59 ` Andrew Morton
2010-12-22  8:17   ` KAMEZAWA Hiroyuki
2010-12-22  8:31     ` KOSAKI Motohiro
2010-12-22  8:48     ` David Rientjes
2010-12-22  8:48       ` KAMEZAWA Hiroyuki
2010-12-22  8:55         ` KAMEZAWA Hiroyuki
2010-12-22  9:21           ` David Rientjes
2010-12-27  1:47             ` KAMEZAWA Hiroyuki
2010-12-22  9:04         ` David Rientjes
2010-12-22  8:42   ` David Rientjes
2010-12-25 10:47 ` Balbir Singh
2010-12-26 20:35   ` 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=alpine.DEB.2.00.1103071657090.24549@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=nishimura@mxp.nes.nec.co.jp \
    /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