Messages in this thread | | | Date | Wed, 8 Jun 2022 10:32:26 +0530 | Subject | Re: [PATCH v5 4/9] mm/demotion: Build demotion targets based on explicit memory tiers | From | Aneesh Kumar K V <> |
| |
On 6/8/22 4:21 AM, Tim Chen wrote: > On Fri, 2022-06-03 at 19:12 +0530, Aneesh Kumar K.V wrote: >> >> +int next_demotion_node(int node) >> +{ >> + struct demotion_nodes *nd; >> + int target, nnodes, i; >> + >> + if (!node_demotion) >> + return NUMA_NO_NODE; >> + >> + nd = &node_demotion[node]; >> + >> + /* >> + * node_demotion[] is updated without excluding this >> + * function from running. >> + * >> + * Make sure to use RCU over entire code blocks if >> + * node_demotion[] reads need to be consistent. >> + */ >> + rcu_read_lock(); >> + >> + nnodes = nodes_weight(nd->preferred); >> + if (!nnodes) >> + return NUMA_NO_NODE; >> + >> + /* >> + * If there are multiple target nodes, just select one >> + * target node randomly. >> + * >> + * In addition, we can also use round-robin to select >> + * target node, but we should introduce another variable >> + * for node_demotion[] to record last selected target node, >> + * that may cause cache ping-pong due to the changing of >> + * last target node. Or introducing per-cpu data to avoid >> + * caching issue, which seems more complicated. So selecting >> + * target node randomly seems better until now. >> + */ >> + nnodes = get_random_int() % nnodes; >> + target = first_node(nd->preferred); >> + for (i = 0; i < nnodes; i++) >> + target = next_node(target, nd->preferred); > > We can simplify the above 4 lines. > > target = node_random(nd->preferred); > > There's still a loop overhead though :( >
Will fix in next update.
>> + >> + rcu_read_unlock(); >> + >> + return target; >> +} >> + >>
-aneesh
| |