From: Michal Hocko <mhocko@kernel.org>
To: Roman Gushchin <guro@fb.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH RFC] mm: don't raise MEMCG_OOM event due to failed high-order allocation
Date: Tue, 11 Sep 2018 14:11:41 +0200 [thread overview]
Message-ID: <20180911121141.GS10951@dhcp22.suse.cz> (raw)
In-Reply-To: <20180910215622.4428-1-guro@fb.com>
On Mon 10-09-18 14:56:22, Roman Gushchin wrote:
> The memcg OOM killer is never invoked due to a failed high-order
> allocation, however the MEMCG_OOM event can be easily raised.
>
> Under some memory pressure it can happen easily because of a
> concurrent allocation. Let's look at try_charge(). Even if we were
> able to reclaim enough memory, this check can fail due to a race
> with another allocation:
>
> if (mem_cgroup_margin(mem_over_limit) >= nr_pages)
> goto retry;
>
> For regular pages the following condition will save us from triggering
> the OOM:
>
> if (nr_reclaimed && nr_pages <= (1 << PAGE_ALLOC_COSTLY_ORDER))
> goto retry;
>
> But for high-order allocation this condition will intentionally fail.
> The reason behind is that we'll likely fall to regular pages anyway,
> so it's ok and even preferred to return ENOMEM.
>
> In this case the idea of raising the MEMCG_OOM event looks dubious.
Why is this a problem though? IIRC this event was deliberately placed
outside of the oom path because we wanted to count allocation failures
and this is also documented that way
oom
The number of time the cgroup's memory usage was
reached the limit and allocation was about to fail.
Depending on context result could be invocation of OOM
killer and retrying allocation or failing a
One could argue that we do not apply the same logic to GFP_NOWAIT
requests but in general I would like to see a good reason to change
the behavior and if it is really the right thing to do then we need to
update the documentation as well.
> Fix this by moving MEMCG_OOM raising to mem_cgroup_oom() after
> allocation order check, so that the event won't be raised for high
> order allocations.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
> ---
> mm/memcontrol.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index fcec9b39e2a3..103ca3c31c04 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1669,6 +1669,8 @@ static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int
> if (order > PAGE_ALLOC_COSTLY_ORDER)
> return OOM_SKIPPED;
>
> + memcg_memory_event(memcg, MEMCG_OOM);
> +
> /*
> * We are in the middle of the charge context here, so we
> * don't want to block when potentially sitting on a callstack
> @@ -2250,8 +2252,6 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> if (fatal_signal_pending(current))
> goto force;
>
> - memcg_memory_event(mem_over_limit, MEMCG_OOM);
> -
> /*
> * keep retrying as long as the memcg oom killer is able to make
> * a forward progress or bypass the charge if the oom killer
> --
> 2.17.1
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-09-11 12:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-10 21:56 Roman Gushchin
2018-09-11 0:40 ` David Rientjes
2018-09-11 12:11 ` Michal Hocko [this message]
2018-09-11 12:41 ` peter enderborg
2018-09-11 12:47 ` Michal Hocko
2018-09-11 15:34 ` Roman Gushchin
2018-09-11 15:27 ` Roman Gushchin
2018-09-12 12:35 ` Michal Hocko
2018-09-12 16:25 ` Roman Gushchin
2018-09-11 12:43 ` Johannes Weiner
2018-09-11 15:47 ` Roman Gushchin
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=20180911121141.GS10951@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vdavydov.dev@gmail.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