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: Thu, 9 Feb 2017 09:57:07 +0100 [thread overview]
Message-ID: <20170209085706.GE10257@dhcp22.suse.cz> (raw)
In-Reply-To: <20170208230618.GA4142@gwshan>
On Thu 09-02-17 10:06:18, Gavin Shan wrote:
> On Wed, Feb 08, 2017 at 11:08:50AM +0100, Michal Hocko wrote:
> >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.
> >
>
> Michael, Yeah, it's a bit confusing. Let me try to summarize the history:
> the code 56608209d34b (2.6.35) depends, which is shown in its commit log,
> was removed by 957f822a0ab9 (3.10). Since then, the code change introduced
> by 56608209d34b (2.6.35) becomes obsoleted. However, the local pagecache
> (with @node_reclaim_mode turned on manually) was able to be shrinked at
> that point (3.10) until 5f7a75acdb24 (3.16) was merged. This patch fixes
> the issue introduced by 5f7a75acdb24 and needs go to 3.16+. Hope this
> makes things more clear, not more confusing :-)
yeah, it is clear as mud ;)
> Yes, I already planned to set PowerPC specific RECLAIM_DISTANCE to 30, same
> value to the generic one, as I said in the last reply of the thread:
> https://patchwork.ozlabs.org/patch/718830/
just drop the ppc specific definition and use the generic one instead.
> >> 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.
> >
>
> Yes, I will post one patch for this and you will be copied.
Thanks!
--
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>
next prev parent reply other threads:[~2017-02-09 8:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-08 5:40 Gavin Shan
2017-02-08 9:28 ` Mel Gorman
2017-02-08 10:08 ` Michal Hocko
2017-02-08 23:06 ` Gavin Shan
2017-02-09 8:57 ` Michal Hocko [this message]
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=20170209085706.GE10257@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