From: "Huang, Ying" <ying.huang@intel.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Dave Hansen <dave.hansen@intel.com>, <akpm@linux-foundation.org>,
<dave.hansen@linux.intel.com>, <ziy@nvidia.com>,
<osalvador@suse.de>, <shy828301@gmail.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm: migrate: Add new node demotion strategy
Date: Mon, 08 Nov 2021 14:48:28 +0800 [thread overview]
Message-ID: <87fss7w3b7.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <9271f9d7-e251-9ed4-2126-8debb3395891@linux.alibaba.com> (Baolin Wang's message of "Mon, 8 Nov 2021 14:38:36 +0800")
Baolin Wang <baolin.wang@linux.alibaba.com> writes:
> On 2021/11/7 23:20, Dave Hansen wrote:
>> On 11/7/21 1:33 AM, Baolin Wang wrote:
>>> Thanks for your suggestion. After some thinking, can we change the
>>> node_demotion[] structure like below? Which means one source node can be
>>> demoted to mutiple target node, and we can set up the target node mask
>>> according to the node distance. How do you think? Thanks.
>>>
>>> static nodemask_t node_demotion[MAX_NUMNODES] __read_mostly =
>>> {[0 ... MAX_NUMNODES - 1] = NODE_MASK_NONE};
>> How large is that in the worst case?
>
> For the worst case (MAX_NUMNODES=1024), the size of the node_demotion
> is 131072 bytes, while the size of original data structure is 4096
> bytes. Maybe we can allocate the node_demotion dynamically?
Per my understanding, in most cases, the number of demotion target nodes
should be quite small. So why not restrict the number of demotion
target nodes to make it some kind of simple array?
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2021-11-08 6:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 9:13 [RFC PATCH] mm: migrate: Add new node demotion strategy Baolin Wang
2021-11-04 15:18 ` Dave Hansen
2021-11-05 2:51 ` Huang, Ying
2021-11-05 15:47 ` Dave Hansen
2021-11-07 9:33 ` Baolin Wang
2021-11-07 15:20 ` Dave Hansen
2021-11-08 6:38 ` Baolin Wang
2021-11-08 6:48 ` Huang, Ying [this message]
2021-11-08 7:07 ` Baolin Wang
2021-11-08 8:12 ` Huang, Ying
2021-11-08 8:43 ` Baolin Wang
2021-11-08 2:12 ` 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=87fss7w3b7.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
--cc=shy828301@gmail.com \
--cc=ziy@nvidia.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).