public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, mgorman@suse.de, akpm@linux-foundation.org,
	anton@samba.org, mpe@ellerman.id.au,
	"# v3 . 16+" <stable@vger.kernel.org>
Subject: Re: [PATCH] mm/page_alloc: Fix nodes for reclaim in fast path
Date: Wed, 8 Feb 2017 11:08:50 +0100	[thread overview]
Message-ID: <20170208100850.GD5686@dhcp22.suse.cz> (raw)
In-Reply-To: <1486532455-29613-1-git-send-email-gwshan@linux.vnet.ibm.com>

On Wed 08-02-17 16:40:55, Gavin Shan wrote:
> When @node_reclaim_node isn't 0, the page allocator tries to reclaim
> pages if the amount of free memory in the zones are below the low
> watermark. On Power platform, none of NUMA nodes are scanned for page
> reclaim because no nodes match the condition in zone_allows_reclaim().
> On Power platform, RECLAIM_DISTANCE is set to 10 which is the distance
> of Node-A to Node-A. So the preferred node even won't be scanned for
> page reclaim.

This is quite confusing. I can see 56608209d34b ("powerpc/numa: Set a
smaller value for RECLAIM_DISTANCE to enable zone reclaim") which
enforced the zone_reclaim by reducing the RECLAIM_DISTANCE, now you are
building on top of that. Having RECLAIM_DISTANCE == LOCAL_DISTANCE is
really confusing. What are distances of other nodes (in other words what
does numactl --hardware tells)? I am wondering whether we shouldn't
rather revert 56608209d34b as the node_reclaim (these days) is not
enabled by default anymore.

[...]

> Fixes: 5f7a75acdb24 ("mm: page_alloc: do not cache reclaim distances")
> Cc: <stable@vger.kernel.org> # v3.16+
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>

anyway the patch looks OK as it brings the previous behavior back. Not
that I would be entirely happy about that behavior as it is quite nasty
- e.g. it will trigger direct reclaim from the allocator fast path way
too much and basically skip the kswapd wake up most of the time if there
is anything reclaimable... But this used to be there before as well.

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

but I would really like to get rid of the ppc specific RECLAIM_DISTANCE
if possible as well.

> ---
>  mm/page_alloc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f3e0c69..1a5f665 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2877,7 +2877,7 @@ bool zone_watermark_ok_safe(struct zone *z, unsigned int order,
>  #ifdef CONFIG_NUMA
>  static bool zone_allows_reclaim(struct zone *local_zone, struct zone *zone)
>  {
> -	return node_distance(zone_to_nid(local_zone), zone_to_nid(zone)) <
> +	return node_distance(zone_to_nid(local_zone), zone_to_nid(zone)) <=
>  				RECLAIM_DISTANCE;
>  }
>  #else	/* CONFIG_NUMA */
> -- 
> 2.7.4
> 
> --
> 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>

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

  parent reply	other threads:[~2017-02-08 10:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-08  5:40 [PATCH] mm/page_alloc: Fix nodes for reclaim in fast path Gavin Shan
2017-02-08  9:28 ` Mel Gorman
2017-02-08 10:08 ` Michal Hocko [this message]
2017-02-08 23:06   ` Gavin Shan
2017-02-09  8:57     ` Michal Hocko
2017-02-08 23:07   ` Gavin Shan

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=20170208100850.GD5686@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anton@samba.org \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mpe@ellerman.id.au \
    --cc=stable@vger.kernel.org \
    /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