All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>,
	Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@quantum.com>,
	Olaf Hering <olaf@aepfle.de>,
	Mel Gorman <mgorman@techsingularity.net>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	David Rientjes <rientjes@google.com>,
	Rik van Riel <riel@redhat.com>,
	Hillf Danton <hillf.zj@alibaba-inc.com>
Subject: Re: [PATCH 4/4] mm, compaction: restrict fragindex to costly orders
Date: Mon, 26 Sep 2016 22:29:12 +0200	[thread overview]
Message-ID: <20160926202912.GC23827@dhcp22.suse.cz> (raw)
In-Reply-To: <20160926162025.21555-5-vbabka@suse.cz>

On Mon 26-09-16 18:20:25, Vlastimil Babka wrote:
> Fragmentation index and the vm.extfrag_threshold sysctl is meant as a heuristic
> to prevent excessive compaction for costly orders (i.e. THP). It's unlikely to
> make any difference for non-costly orders, especially with the default
> threshold. But we cannot afford any uncertainty for the non-costly orders where
> the only alternative to successful reclaim/compaction is OOM. After the recent
> patches we are guaranteed maximum effort without heuristics from compaction
> before deciding OOM, and fragindex is the last remaining heuristic. Therefore
> skip fragindex altogether for non-costly orders.

It would be nicer to reduce this just to the highest compaction priority
but as your previous attempt shows this adds a lot of code churn.
Not skipping the compaction for these !costly orders might lead to a
higher latency for the allocation due to pointless zone scanning but
considering that an alternative would be the order-0 reclaim which
doesn't guarantee any larger blocks then doing a more targeted approach
sounds quite reasonable to me.

This patch is not really needed to prevent pre-mature OOMs because
compaction_zonelist_suitable doesn't rely on the fragmentation index
after the previous patch but it makes sense to me regardless. The
fagindex was quite an obscure measure and having !costly order easier to
understand is valuable imho.

> Suggested-by: Michal Hocko <mhocko@suse.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Rik van Riel <riel@redhat.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/compaction.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 5ff7f801c345..badb92bf14b4 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1435,9 +1435,14 @@ enum compact_result compaction_suitable(struct zone *zone, int order,
>  	 * index towards 0 implies failure is due to lack of memory
>  	 * index towards 1000 implies failure is due to fragmentation
>  	 *
> -	 * Only compact if a failure would be due to fragmentation.
> +	 * Only compact if a failure would be due to fragmentation. Also
> +	 * ignore fragindex for non-costly orders where the alternative to
> +	 * a successful reclaim/compaction is OOM. Fragindex and the
> +	 * vm.extfrag_threshold sysctl is meant as a heuristic to prevent
> +	 * excessive compaction for costly orders, but it should not be at the
> +	 * expense of system stability.
>  	 */
> -	if (ret == COMPACT_CONTINUE) {
> +	if (ret == COMPACT_CONTINUE && (order > PAGE_ALLOC_COSTLY_ORDER)) {
>  		fragindex = fragmentation_index(zone, order);
>  		if (fragindex >= 0 && fragindex <= sysctl_extfrag_threshold)
>  			return COMPACT_NOT_SUITABLE_ZONE;
> -- 
> 2.10.0

-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>,
	Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@quantum.com>,
	Olaf Hering <olaf@aepfle.de>,
	Mel Gorman <mgorman@techsingularity.net>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	David Rientjes <rientjes@google.com>,
	Rik van Riel <riel@redhat.com>,
	Hillf Danton <hillf.zj@alibaba-inc.com>
Subject: Re: [PATCH 4/4] mm, compaction: restrict fragindex to costly orders
Date: Mon, 26 Sep 2016 22:29:12 +0200	[thread overview]
Message-ID: <20160926202912.GC23827@dhcp22.suse.cz> (raw)
In-Reply-To: <20160926162025.21555-5-vbabka@suse.cz>

On Mon 26-09-16 18:20:25, Vlastimil Babka wrote:
> Fragmentation index and the vm.extfrag_threshold sysctl is meant as a heuristic
> to prevent excessive compaction for costly orders (i.e. THP). It's unlikely to
> make any difference for non-costly orders, especially with the default
> threshold. But we cannot afford any uncertainty for the non-costly orders where
> the only alternative to successful reclaim/compaction is OOM. After the recent
> patches we are guaranteed maximum effort without heuristics from compaction
> before deciding OOM, and fragindex is the last remaining heuristic. Therefore
> skip fragindex altogether for non-costly orders.

It would be nicer to reduce this just to the highest compaction priority
but as your previous attempt shows this adds a lot of code churn.
Not skipping the compaction for these !costly orders might lead to a
higher latency for the allocation due to pointless zone scanning but
considering that an alternative would be the order-0 reclaim which
doesn't guarantee any larger blocks then doing a more targeted approach
sounds quite reasonable to me.

This patch is not really needed to prevent pre-mature OOMs because
compaction_zonelist_suitable doesn't rely on the fragmentation index
after the previous patch but it makes sense to me regardless. The
fagindex was quite an obscure measure and having !costly order easier to
understand is valuable imho.

> Suggested-by: Michal Hocko <mhocko@suse.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Rik van Riel <riel@redhat.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/compaction.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 5ff7f801c345..badb92bf14b4 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1435,9 +1435,14 @@ enum compact_result compaction_suitable(struct zone *zone, int order,
>  	 * index towards 0 implies failure is due to lack of memory
>  	 * index towards 1000 implies failure is due to fragmentation
>  	 *
> -	 * Only compact if a failure would be due to fragmentation.
> +	 * Only compact if a failure would be due to fragmentation. Also
> +	 * ignore fragindex for non-costly orders where the alternative to
> +	 * a successful reclaim/compaction is OOM. Fragindex and the
> +	 * vm.extfrag_threshold sysctl is meant as a heuristic to prevent
> +	 * excessive compaction for costly orders, but it should not be at the
> +	 * expense of system stability.
>  	 */
> -	if (ret == COMPACT_CONTINUE) {
> +	if (ret == COMPACT_CONTINUE && (order > PAGE_ALLOC_COSTLY_ORDER)) {
>  		fragindex = fragmentation_index(zone, order);
>  		if (fragindex >= 0 && fragindex <= sysctl_extfrag_threshold)
>  			return COMPACT_NOT_SUITABLE_ZONE;
> -- 
> 2.10.0

-- 
Michal Hocko
SUSE Labs

--
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>

  reply	other threads:[~2016-09-26 20:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-26 16:20 [PATCH 0/4] followups to reintroduce compaction feedback for OOM decisions Vlastimil Babka
2016-09-26 16:20 ` Vlastimil Babka
2016-09-26 16:20 ` [PATCH 1/4] mm, compaction: more reliably increase direct compaction priority-fix Vlastimil Babka
2016-09-26 16:20   ` Vlastimil Babka
2016-09-27  3:25   ` Hillf Danton
2016-09-27  3:25     ` Hillf Danton
2016-09-26 16:20 ` [PATCH 2/4] mm, page_alloc: pull no_progress_loops update to should_reclaim_retry() Vlastimil Babka
2016-09-26 16:20   ` Vlastimil Babka
2016-09-26 16:20 ` [PATCH 3/4] mm, compaction: ignore fragindex from compaction_zonelist_suitable() Vlastimil Babka
2016-09-26 16:20   ` Vlastimil Babka
2016-09-26 20:15   ` Michal Hocko
2016-09-26 20:15     ` Michal Hocko
2016-09-29  9:57   ` Vlastimil Babka
2016-09-29  9:57     ` Vlastimil Babka
2016-09-26 16:20 ` [PATCH 4/4] mm, compaction: restrict fragindex to costly orders Vlastimil Babka
2016-09-26 16:20   ` Vlastimil Babka
2016-09-26 20:29   ` Michal Hocko [this message]
2016-09-26 20:29     ` 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=20160926202912.GC23827@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=Ralf-Peter.Rohbeck@quantum.com \
    --cc=a.miskiewicz@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=olaf@aepfle.de \
    --cc=riel@redhat.com \
    --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.