linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	azurit@pobox.sk, mm-commits@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [merged] mm-memcg-handle-non-error-oom-situations-more-gracefully.patch removed from -mm tree
Date: Mon, 2 Dec 2013 14:12:38 +0100	[thread overview]
Message-ID: <20131202131238.GB18838@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.02.1311291600290.22413@chino.kir.corp.google.com>

On Fri 29-11-13 16:05:04, David Rientjes wrote:
> On Thu, 28 Nov 2013, Michal Hocko wrote:
> 
> > > None that I am currently aware of,
> > 
> > Are you saing that scenarios described in 3812c8c8f395 (mm: memcg: do not
> > trap chargers with full callstack on OOM) are not real or that _you_
> > haven't seen an issue like that?
> > 
> > The later doesn't seem to be so relevant as we had at least one user who
> > has seen those in the real life.
> > 
> 
> I said I'm not currently aware of any additional problems with the 
> patchset,

I have obviously misread your reply. Sorry about that.

> but since Johannes said the entire series wasn't meant for that 
> merge window, I asked if it was still being worked on.
> 
> > > You don't think something like this is helpful after scanning a memcg will 
> > > a large number of processes?
> > 
> > It looks as a one-shot workaround for short lived processes to me.
> 
> It has nothing to do with how long a process has been running, both racing 
> processes could have been running for years.  It's obvious that even this 
> patch before calling oom_kill_process() does not catch a racing process 
> that has already freed its memory and is exiting but it makes the 
> liklihood significantly less in testing at scale. 

I guess we need to know how much is significantly less.
oom_scan_process_thread already aborts on exiting tasks so we do not
kill anything and then the charge (whole page fault actually) is retried
when we check for the OOM again so my intuition would say that we gave
the exiting task quite a lot of time.

> It's simply better to avoid unnecessary oom killing at anytime
> possible and this is not a hotpath.

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

  reply	other threads:[~2013-12-02 13:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <526028bd.k5qPj2+MDOK1o6ii%akpm@linux-foundation.org>
2013-11-27 23:08 ` David Rientjes
2013-11-27 23:33   ` Johannes Weiner
2013-11-28  0:56     ` David Rientjes
2013-11-28  2:18       ` Johannes Weiner
2013-11-28  2:38         ` David Rientjes
2013-11-28  3:13           ` Johannes Weiner
2013-11-28  3:20             ` David Rientjes
2013-11-28  3:52               ` Johannes Weiner
2013-11-30  0:00                 ` David Rientjes
2013-11-30  0:51                   ` Greg KH
2013-11-30 10:25                     ` David Rientjes
2013-11-30  3:35                   ` Johannes Weiner
2013-11-30 10:32                     ` David Rientjes
2013-11-30 15:55                       ` Johannes Weiner
2013-11-30 22:12                         ` David Rientjes
2013-11-28 10:02               ` Michal Hocko
2013-11-30  0:05                 ` David Rientjes
2013-12-02 13:12                   ` Michal Hocko [this message]
2013-12-02 22:51                     ` David Rientjes
2013-11-28  9:12     ` Michal Hocko
2013-11-30  3:37       ` Johannes Weiner

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=20131202131238.GB18838@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=azurit@pobox.sk \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mm-commits@vger.kernel.org \
    --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