linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.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: Tue, 3 Apr 2018 10:54:08 -0400	[thread overview]
Message-ID: <20180403145408.GA21411@cmpxchg.org> (raw)
In-Reply-To: <alpine.DEB.2.20.1803211418170.107059@chino.kir.corp.google.com>

On Wed, Mar 21, 2018 at 02:22:13PM -0700, David Rientjes wrote:
> 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.

I agree with your premise: unlike the page allocator, memcg could OOM
kill to help satisfy higher order allocations.

Technically.

But the semantics and expectations matter too.

Because of the allocator's restriction, we've been telling and
teaching callsites to fail gracefully and implement fallbacks forever,
and that makes costly-order allocations inherently speculative and to
a certain extent often optional. They've been written with that in
mind forever.

OOM is not graceful failure, though. We don't want to OOM kill when an
the callsite can easily fallback to smaller allocations, trigger a
packet resend, fail the syscall, what have you.

We could argue what the default should be if callsites aren't
specifically annotated - and whether we should change it.

But the page allocator has established the default behavior already,
and this is a bugfix. I prefer this fix not fundamentally change
semantics for costly-order allocations.

  parent reply	other threads:[~2018-04-03 14:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 20:59 [PATCH] memcg, thp: do not invoke oom killer on thp charges Michal Hocko
2018-03-21 21:22 ` David Rientjes
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 [this message]
2018-04-03 14:58 ` Johannes Weiner
2018-04-03 15:55   ` Michal Hocko
2018-04-03 18:11     ` Johannes Weiner
  -- strict thread matches above, loose matches on Subject: below --
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=20180403145408.GA21411@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.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=rientjes@google.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;
as well as URLs for NNTP newsgroup(s).