From: "Hillf Danton" <hillf.zj@alibaba-inc.com>
To: 'Michal Hocko' <mhocko@kernel.org>,
'Andrew Morton' <akpm@linux-foundation.org>
Cc: 'Linus Torvalds' <torvalds@linux-foundation.org>,
'Johannes Weiner' <hannes@cmpxchg.org>,
'Mel Gorman' <mgorman@suse.de>,
'David Rientjes' <rientjes@google.com>,
'Tetsuo Handa' <penguin-kernel@I-love.SAKURA.ne.jp>,
'Joonsoo Kim' <js1304@gmail.com>,
'Vlastimil Babka' <vbabka@suse.cz>,
linux-mm@kvack.org, 'LKML' <linux-kernel@vger.kernel.org>,
'Michal Hocko' <mhocko@suse.com>
Subject: Re: [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION
Date: Fri, 13 May 2016 12:05:49 +0800 [thread overview]
Message-ID: <02ee01d1accc$bc7e6180$357b2480$@alibaba-inc.com> (raw)
In-Reply-To: <1463051677-29418-3-git-send-email-mhocko@kernel.org>
> From: Michal Hocko <mhocko@suse.com>
>
> Joonsoo has reported that he is able to trigger OOM for !costly high
> order requests (heavy fork() workload close the OOM) with the new
> oom detection rework. This is because we rely only on should_reclaim_retry
> when the compaction is disabled and it only checks watermarks for the
> requested order and so we might trigger OOM when there is a lot of free
> memory.
>
> It is not very clear what are the usual workloads when the compaction
> is disabled. Relying on high order allocations heavily without any
> mechanism to create those orders except for unbound amount of reclaim is
> certainly not a good idea.
>
> To prevent from potential regressions let's help this configuration
> some. We have to sacrifice the determinsm though because there simply is
> none here possible. should_compact_retry implementation for
> !CONFIG_COMPACTION, which was empty so far, will do watermark check
> for order-0 on all eligible zones. This will cause retrying until either
> the reclaim cannot make any further progress or all the zones are
> depleted even for order-0 pages. This means that the number of retries
> is basically unbounded for !costly orders but that was the case before
> the rework as well so this shouldn't regress.
>
> Reported-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
> mm/page_alloc.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 620ec002aea2..7e2defbfe55b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3310,6 +3310,24 @@ should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_fla
> enum migrate_mode *migrate_mode,
> int compaction_retries)
> {
> + struct zone *zone;
> + struct zoneref *z;
> +
> + if (!order || order > PAGE_ALLOC_COSTLY_ORDER)
> + return false;
> +
> + /*
> + * There are setups with compaction disabled which would prefer to loop
> + * inside the allocator rather than hit the oom killer prematurely. Let's
> + * give them a good hope and keep retrying while the order-0 watermarks
> + * are OK.
> + */
> + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx,
> + ac->nodemask) {
> + if(zone_watermark_ok(zone, 0, min_wmark_pages(zone),
s/if(zone_/if (zone_/
> + ac_classzone_idx(ac), alloc_flags))
> + return true;
> + }
> return false;
> }
> #endif /* CONFIG_COMPACTION */
> --
> 2.8.1
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: "Hillf Danton" <hillf.zj@alibaba-inc.com>
To: "'Michal Hocko'" <mhocko@kernel.org>,
"'Andrew Morton'" <akpm@linux-foundation.org>
Cc: "'Linus Torvalds'" <torvalds@linux-foundation.org>,
"'Johannes Weiner'" <hannes@cmpxchg.org>,
"'Mel Gorman'" <mgorman@suse.de>,
"'David Rientjes'" <rientjes@google.com>,
"'Tetsuo Handa'" <penguin-kernel@I-love.SAKURA.ne.jp>,
"'Joonsoo Kim'" <js1304@gmail.com>,
"'Vlastimil Babka'" <vbabka@suse.cz>, <linux-mm@kvack.org>,
"'LKML'" <linux-kernel@vger.kernel.org>,
"'Michal Hocko'" <mhocko@suse.com>
Subject: Re: [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION
Date: Fri, 13 May 2016 12:05:49 +0800 [thread overview]
Message-ID: <02ee01d1accc$bc7e6180$357b2480$@alibaba-inc.com> (raw)
In-Reply-To: <1463051677-29418-3-git-send-email-mhocko@kernel.org>
> From: Michal Hocko <mhocko@suse.com>
>
> Joonsoo has reported that he is able to trigger OOM for !costly high
> order requests (heavy fork() workload close the OOM) with the new
> oom detection rework. This is because we rely only on should_reclaim_retry
> when the compaction is disabled and it only checks watermarks for the
> requested order and so we might trigger OOM when there is a lot of free
> memory.
>
> It is not very clear what are the usual workloads when the compaction
> is disabled. Relying on high order allocations heavily without any
> mechanism to create those orders except for unbound amount of reclaim is
> certainly not a good idea.
>
> To prevent from potential regressions let's help this configuration
> some. We have to sacrifice the determinsm though because there simply is
> none here possible. should_compact_retry implementation for
> !CONFIG_COMPACTION, which was empty so far, will do watermark check
> for order-0 on all eligible zones. This will cause retrying until either
> the reclaim cannot make any further progress or all the zones are
> depleted even for order-0 pages. This means that the number of retries
> is basically unbounded for !costly orders but that was the case before
> the rework as well so this shouldn't regress.
>
> Reported-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
> mm/page_alloc.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 620ec002aea2..7e2defbfe55b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3310,6 +3310,24 @@ should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_fla
> enum migrate_mode *migrate_mode,
> int compaction_retries)
> {
> + struct zone *zone;
> + struct zoneref *z;
> +
> + if (!order || order > PAGE_ALLOC_COSTLY_ORDER)
> + return false;
> +
> + /*
> + * There are setups with compaction disabled which would prefer to loop
> + * inside the allocator rather than hit the oom killer prematurely. Let's
> + * give them a good hope and keep retrying while the order-0 watermarks
> + * are OK.
> + */
> + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx,
> + ac->nodemask) {
> + if(zone_watermark_ok(zone, 0, min_wmark_pages(zone),
s/if(zone_/if (zone_/
> + ac_classzone_idx(ac), alloc_flags))
> + return true;
> + }
> return false;
> }
> #endif /* CONFIG_COMPACTION */
> --
> 2.8.1
next prev parent reply other threads:[~2016-05-13 4:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 11:14 [PATCH 0/2] oom detection fixups Michal Hocko
2016-05-12 11:14 ` Michal Hocko
2016-05-12 11:14 ` [PATCH 1/2] mmotm: mm-oom-rework-oom-detection-fix Michal Hocko
2016-05-12 11:14 ` Michal Hocko
2016-05-13 3:59 ` Hillf Danton
2016-05-13 3:59 ` Hillf Danton
2016-05-12 11:14 ` [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION Michal Hocko
2016-05-12 11:14 ` Michal Hocko
2016-05-13 4:05 ` Hillf Danton [this message]
2016-05-13 4:05 ` Hillf Danton
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='02ee01d1accc$bc7e6180$357b2480$@alibaba-inc.com' \
--to=hillf.zj@alibaba-inc.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
--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 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.