All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Greg Thelen <gthelen@google.com>,
	Shakeel Butt <shakeelb@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] memcg, oom: move out_of_memory back to the charge path
Date: Wed, 20 Jun 2018 15:35:49 -0400	[thread overview]
Message-ID: <20180620193549.GA4734@cmpxchg.org> (raw)
In-Reply-To: <20180620153148.GO13685@dhcp22.suse.cz>

On Wed, Jun 20, 2018 at 05:31:48PM +0200, Michal Hocko wrote:
> This?
> 	if (order > PAGE_ALLOC_COSTLY_ORDER)
> 		return OOM_SKIPPED;
> 
> 	/*
> 	 * We are in the middle of the charge context here, so we
> 	 * don't want to block when potentially sitting on a callstack
> 	 * that holds all kinds of filesystem and mm locks.
> 	 *
> 	 * cgroup1 allows disabling the OOM killer and waiting for outside
> 	 * handling until the charge can succeed; remember the context and put
> 	 * the task to sleep at the end of the page fault when all locks are
> 	 * released.
> 	 *
> 	 * On the other hand, in-kernel OOM killer allows for an async victim
> 	 * memory reclaim (oom_reaper) and that means that we are not solely
> 	 * relying on the oom victim to make a forward progress and we can
> 	 * invoke the oom killer here.
> 	 *
> 	 * Please note that mem_cgroup_oom_synchronize might fail to find a
> 	 * victim and then we have rely on mem_cgroup_oom_synchronize otherwise
> 	 * we would fall back to the global oom killer in pagefault_out_of_memory
> 	 */
> 	if (memcg->oom_kill_disable) {
> 		if (!current->memcg_may_oom)
> 			return OOM_SKIPPED;
> 		css_get(&memcg->css);
> 		current->memcg_in_oom = memcg;
> 		current->memcg_oom_gfp_mask = mask;
> 		current->memcg_oom_order = order;
> 
> 		return OOM_ASYNC;
> 	}
> 
> 	if (mem_cgroup_out_of_memory(memcg, mask, order))
> 		return OOM_SUCCESS;
> 
> 	WARN(!current->memcg_may_oom,
> 			"Memory cgroup charge failed because of no reclaimable memory! "
> 			"This looks like a misconfiguration or a kernel bug.");
> 	return OOM_FAILED;

Yep, this looks good IMO.

  parent reply	other threads:[~2018-06-20 19:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 10:37 [RFC PATCH] memcg, oom: move out_of_memory back to the charge path Michal Hocko
2018-06-20 10:37 ` Michal Hocko
2018-06-20 15:18 ` Johannes Weiner
2018-06-20 15:31   ` Michal Hocko
2018-06-20 15:34     ` Michal Hocko
2018-06-20 19:35     ` Johannes Weiner [this message]
2018-06-20 19:38     ` Johannes Weiner
2018-06-21  7:36       ` Michal Hocko
2018-06-21  8:09 ` Michal Hocko
2018-06-21  8:09   ` Michal Hocko
2018-06-21 14:37   ` Johannes Weiner
2018-06-21 15:05     ` 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=20180620193549.GA4734@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=gthelen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=shakeelb@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 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.