From: David Rientjes <rientjes@google.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] memcg, thp: do not invoke oom killer on thp charges
Date: Wed, 21 Mar 2018 14:22:13 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.20.1803211418170.107059@chino.kir.corp.google.com> (raw)
In-Reply-To: <20180321205928.22240-1-mhocko@kernel.org>
On Wed, 21 Mar 2018, Michal Hocko wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index d1a917b5b7b7..08accbcd1a18 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1493,7 +1493,7 @@ static void memcg_oom_recover(struct mem_cgroup *memcg)
>
> static void mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
> {
> - if (!current->memcg_may_oom)
> + if (!current->memcg_may_oom || order > PAGE_ALLOC_COSTLY_ORDER)
> return;
> /*
> * We are in the middle of the charge context here, so we
What bug reports have you received about order-4 and higher order non thp
charges that this fixes?
The patch title and the changelog specifically single out thp, which I've
fixed, since it has sane fallback behavior and everything else uses
__GFP_NORETRY. I think this is misusing a page allocator heuristic that
hasn't been applied to the memcg charge path before to address a thp
regression but generalizing it for all charges.
PAGE_ALLOC_COSTLY_ORDER is a heuristic used by the page allocator because
it cannot free high-order contiguous memory. Memcg just needs to reclaim
a number of pages. Two order-3 charges can cause a memcg oom kill but now
an order-4 charge cannot. It's an unfair bias against high-order charges
that are not explicitly using __GFP_NORETRY.
next prev parent reply other threads:[~2018-03-21 21:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 20:59 Michal Hocko
2018-03-21 21:22 ` David Rientjes [this message]
2018-03-21 21:41 ` Michal Hocko
2018-03-22 8:26 ` David Rientjes
2018-03-22 8:56 ` Michal Hocko
2018-03-22 20:29 ` David Rientjes
2018-03-23 9:07 ` Michal Hocko
2018-03-23 9:26 ` David Rientjes
2018-04-03 14:54 ` Johannes Weiner
2018-04-03 14:58 ` Johannes Weiner
2018-04-03 15:55 ` Michal Hocko
2018-04-03 18:11 ` Johannes Weiner
2018-04-03 19:31 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=alpine.DEB.2.20.1803211418170.107059@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=vbabka@suse.cz \
/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