All of lore.kernel.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: 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>

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