Messages in this thread | | | Subject | Re: [RFC PATCH] mm: migrate: Add new node demotion strategy | From | Baolin Wang <> | Date | Mon, 8 Nov 2021 16:43:37 +0800 |
| |
On 2021/11/8 16:12, Huang, Ying writes: > Baolin Wang <baolin.wang@linux.alibaba.com> writes: > >> On 2021/11/8 14:48, Huang, Ying writes: >>> 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? >> >> Yes, agree. Something like below is reasonable for you? >> >> #define DEMOTION_TARGET_NODES 16 >> typedef struct { DECLARE_BITMAP(bits, DEMOTION_TARGET_NODES); } >> demotemask_t; >> >> static demotemask_t node_demotion[MAX_NUMNODES]; > > I don't think we need a bitmap. May be something as following, > > #define DEMOTION_TARGET_NODES 15 > struct demotion_nodes { > unsigned short nr; > unsigned short nodes[DEMOTION_TARGET_NODES]; > };
OK. Let me try it in next version. Thanks.
| |