linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Huang Ying <ying.huang@intel.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Yu Zhao <yuzhao@google.com>,
	Hillf Danton <hdanton@sina.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Matthew Wilcox <willy@infradead.org>,
	Michal Hocko <mhocko@suse.com>, Roman Gushchin <guro@fb.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	Yang Shi <shy828301@gmail.com>
Subject: Re: [RFC] mm: activate access-more-than-once page via NUMA balancing
Date: Wed, 24 Mar 2021 10:31:04 +0000	[thread overview]
Message-ID: <20210324103104.GN15768@suse.de> (raw)
In-Reply-To: <20210324083209.527427-1-ying.huang@intel.com>

On Wed, Mar 24, 2021 at 04:32:09PM +0800, Huang Ying wrote:
> One idea behind the LRU page reclaiming algorithm is to put the
> access-once pages in the inactive list and access-more-than-once pages
> in the active list.  This is true for the file pages that are accessed
> via syscall (read()/write(), etc.), but not for the pages accessed via
> the page tables.  We can only activate them via page reclaim scanning
> now.  This may cause some problems.  For example, even if there are
> only hot file pages accessed via the page tables in the inactive list,
> we will enable the cache trim mode incorrectly to scan only the hot
> file pages instead of cold anon pages.
> 

I caution against this patch.

It's non-deterministic for a number of reasons. As it requires NUMA
balancing to be enabled, the pageout behaviour of a system changes when
NUMA balancing is active. If this led to pages being artificially and
inappropriately preserved, NUMA balancing could be disabled for the
wrong reasons.  It only applies to pages that have no target node so
memory policies affect which pages are activated differently. Similarly,
NUMA balancing does not scan all VMAs and some pages may never trap a
NUMA fault as a result. The timing of when an address space gets scanned
is driven by the locality of pages and so the timing of page activation
potentially becomes linked to whether pages are local or need to migrate
(although not right now for this patch as it only affects pages with a
target nid of NUMA_NO_NODE). In other words, changes in NUMA balancing
that affect migration potentially affect the aging rate.  Similarly,
the activate rate of a process with a single thread and multiple threads
potentially have different activation rates.

Finally, the NUMA balancing scan algorithm is sub-optimal. It potentially
scans the entire address space even though only a small number of pages
are scanned. This is particularly problematic when a process has a lot
of threads because threads are redundantly scanning the same regions. If
NUMA balancing ever introduced range tracking of faulted pages to limit
how much scanning it has to do, it would inadvertently cause a change in
page activation rate.

NUMA balancing is about page locality, it should not get conflated with
page aging.

-- 
Mel Gorman
SUSE Labs


  reply	other threads:[~2021-03-24 10:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24  8:32 [RFC] mm: activate access-more-than-once page via NUMA balancing Huang Ying
2021-03-24 10:31 ` Mel Gorman [this message]
2021-03-25  4:33   ` Huang, Ying
2021-03-25 11:57     ` Mel Gorman
2021-03-26  6:20       ` Huang, Ying
2021-04-10 22:25         ` Yu Zhao
2021-04-13  5:42           ` Huang, Ying

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=20210324103104.GN15768@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=hdanton@sina.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=shy828301@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --cc=yuzhao@google.com \
    /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;
as well as URLs for NNTP newsgroup(s).