From: "Huang\, Ying" <ying.huang@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<yang.shi@linux.alibaba.com>, <rientjes@google.com>,
<dan.j.williams@intel.com>
Subject: Re: [RFC][PATCH 5/8] mm/numa: automatically generate node migration order
Date: Thu, 02 Jul 2020 09:20:00 +0800 [thread overview]
Message-ID: <878sg2lnlr.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <3ef8a701-fe8a-cf65-5b72-806b244aae8b@intel.com> (Dave Hansen's message of "Wed, 1 Jul 2020 11:23:00 -0700")
Dave Hansen <dave.hansen@intel.com> writes:
> On 6/30/20 1:22 AM, Huang, Ying wrote:
>>> + /*
>>> + * To avoid cycles in the migration "graph", ensure
>>> + * that migration sources are not future targets by
>>> + * setting them in 'used_targets'.
>>> + *
>>> + * But, do this only once per pass so that multiple
>>> + * source nodes can share a target node.
>> establish_migrate_target() calls find_next_best_node(), which will set
>> target_node in used_targets. So it seems that the nodes_or() below is
>> only necessary to initialize used_targets, and multiple source nodes
>> cannot share one target node in current implementation.
>
> Yes, that is true. My focus on this implementation was simplicity and
> sanity for common configurations. I can certainly imagine scenarios
> where this is suboptimal.
>
> I'm totally open to other ways of doing this.
OK. So when we really need to share one target node for multiple source
nodes, we can add a parameter to find_next_best_node() to specify
whether set target_node in used_targets.
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2020-07-02 1:20 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 23:45 [RFC][PATCH 0/8] Migrate Pages in lieu of discard Dave Hansen
2020-06-29 23:45 ` [RFC][PATCH 1/8] mm/numa: node demotion data structure and lookup Dave Hansen
2020-06-29 23:45 ` [RFC][PATCH 2/8] mm/migrate: Defer allocating new page until needed Dave Hansen
2020-07-01 8:47 ` Greg Thelen
2020-07-01 14:46 ` Dave Hansen
2020-07-01 18:32 ` Yang Shi
2020-06-29 23:45 ` [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of discard Dave Hansen
2020-07-01 0:47 ` David Rientjes
2020-07-01 1:29 ` Yang Shi
2020-07-01 5:41 ` David Rientjes
2020-07-01 8:54 ` Huang, Ying
2020-07-01 18:20 ` Dave Hansen
2020-07-01 19:50 ` David Rientjes
2020-07-02 1:50 ` Huang, Ying
2020-07-01 15:15 ` Dave Hansen
2020-07-01 17:21 ` Yang Shi
2020-07-01 19:45 ` David Rientjes
2020-07-02 10:02 ` Jonathan Cameron
2020-07-01 1:40 ` Huang, Ying
2020-07-01 16:48 ` Dave Hansen
2020-07-01 19:25 ` David Rientjes
2020-07-02 5:02 ` Huang, Ying
2020-06-29 23:45 ` [RFC][PATCH 4/8] mm/vmscan: add page demotion counter Dave Hansen
2020-06-29 23:45 ` [RFC][PATCH 5/8] mm/numa: automatically generate node migration order Dave Hansen
2020-06-30 8:22 ` Huang, Ying
2020-07-01 18:23 ` Dave Hansen
2020-07-02 1:20 ` Huang, Ying [this message]
2020-06-29 23:45 ` [RFC][PATCH 6/8] mm/vmscan: Consider anonymous pages without swap Dave Hansen
2020-06-29 23:45 ` [RFC][PATCH 7/8] mm/vmscan: never demote for memcg reclaim Dave Hansen
2020-06-29 23:45 ` [RFC][PATCH 8/8] mm/numa: new reclaim mode to enable reclaim-based migration Dave Hansen
2020-06-30 7:23 ` Huang, Ying
2020-06-30 17:50 ` Yang Shi
2020-07-01 0:48 ` Huang, Ying
2020-07-01 1:12 ` Yang Shi
2020-07-01 1:28 ` Huang, Ying
2020-07-01 16:02 ` Dave Hansen
2020-07-03 9:30 ` Huang, Ying
2020-06-30 18:36 ` [RFC][PATCH 0/8] Migrate Pages in lieu of discard Shakeel Butt
2020-06-30 18:51 ` Dave Hansen
2020-06-30 19:25 ` Shakeel Butt
2020-06-30 19:31 ` Dave Hansen
2020-07-01 14:24 ` [RFC] [PATCH " Zi Yan
2020-07-01 14:32 ` Dave Hansen
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=878sg2lnlr.fsf@yhuang-dev.intel.com \
--to=ying.huang@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=yang.shi@linux.alibaba.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).