On Fri, Jul 30, 2021 at 08:36:50AM +0200, Michal Hocko wrote: > On Fri 30-07-21 11:05:02, Feng Tang wrote: > > On Thu, Jul 29, 2021 at 06:21:19PM +0200, Michal Hocko wrote: > > > On Thu 29-07-21 23:12:42, Feng Tang wrote: > > > > On Thu, Jul 29, 2021 at 03:38:44PM +0200, Michal Hocko wrote: > > > [...] > > > > > Also the > > > > > semantic to give nodes some ordering based on their numbers sounds > > > > > rather weird to me. > > > > > > > > I agree, and as I admitted in the first reply, this need to be fixed. > > > > > > OK. I was not really clear that we are on the same page here. > > > > > > > > The semantic I am proposing is to allocate from prefered nodes in > > > > > distance order starting from the local node. > > > > > > > > So the plan is: > > > > * if the local node is set in 'prefer-many's nodemask, then chose > > > > * otherwise chose the node with the shortest distance to local node > > > > ? > > > > > > Yes and what I am trying to say is that you will achieve that simply by > > > doing the following in policy_node: > > > if (policy->mode == MPOL_PREFERRED_MANY) > > > return nd; > > > > One thing is, it's possible that 'nd' is not set in the preferred > > nodemask. > > Yes, and there shouldn't be any problem with that. The given node is > only used to get the respective zonelist (order distance ordered list of > zones to try). get_page_from_freelist will then use the preferred node > mask to filter this zone list. Is that more clear now? Yes, from the code, the policy_node() is always coupled with policy_nodemask(), which secures the 'nodemask' limit. Thanks for the clarification! And for the mempolicy_slab_node(), it seems to be a little different, and we may need to reuse its logic for 'bind' policy, which is similar to what we've discussed, pick a nearest node to the local node. And similar for mpol_misplaced(). Thoughts? Thanks, Feng > -- > Michal Hocko > SUSE Labs