Re: [v3 PATCH 2/3] mm/mempolicy: don't handle MPOL_LOCAL like a fake MPOL_PREFERRED policy

[Feng Tang]

On Tue, Jun 01, 2021 at 10:44:39AM +0200, Michal Hocko wrote:
> On Mon 31-05-21 22:05:55, Feng Tang wrote:
> > MPOL_LOCAL policy has been setup as a real policy, but it is still
> > handled like a faked POL_PREFERRED policy with one internal
> > MPOL_F_LOCAL flag bit set, and there are many places having to
> > judge the real 'prefer' or the 'local' policy, which are quite
> > confusing.
> > 
> > In current code, there are 4 cases that MPOL_LOCAL are used:
> > 1. user specifies 'local' policy
> > 2. user specifies 'prefer' policy, but with empty nodemask
> > 3. system 'default' policy is used
> > 4. 'prefer' policy + valid 'preferred' node with MPOL_F_STATIC_NODES
> >    flag set, and when it is 'rebind' to a nodemask which doesn't
> >    contains the 'preferred' node, it will perform as 'local' policy
> > 
> > So make 'local' a real policy instead of a fake 'prefer' one, and
> > kill MPOL_F_LOCAL bit, which can greatly reduce the confusion for
> > code reading.
> > 
> > For case 4, the logic of mpol_rebind_preferred() is confusing, as
> > Michal Hocko pointed out:
> > 
> >  "
> >  I do believe that rebinding preferred policy is just bogus and
> >  it should be dropped altogether on the ground that a preference
> >  is a mere hint from userspace where to start the allocation.
> >  Unless I am missing something cpusets will be always authoritative
> >  for the final placement. The preferred node just acts as a starting
> >  point and it should be really preserved when cpusets changes.
> >  Otherwise we have a very subtle behavior corner cases.
> >  "
> > So dump all the tricky transformation between 'prefer' and 'local',
> > and just record the new nodemask of rebinding.
> > 
> > Suggested-by: Michal Hocko <mhocko@xxxxxxxx>
> > Signed-off-by: Feng Tang <feng.tang@xxxxxxxxx>
> 
> I like this very much! It simplifies a tricky code and also a very
> dubious behavior. I would like to hear from others whether there might
> be some userspace depending on this obscure behavior though. One never
> knows...
> 
> Some more notes/questions below
> 
> [...]
> > @@ -239,25 +240,19 @@ static int mpol_set_nodemask(struct mempolicy *pol,
> >  		  cpuset_current_mems_allowed, node_states[N_MEMORY]);
> >  
> >  	VM_BUG_ON(!nodes);
> > -	if (pol->mode == MPOL_PREFERRED && nodes_empty(*nodes))
> > -		nodes = NULL;	/* explicit local allocation */
> > -	else {
> > -		if (pol->flags & MPOL_F_RELATIVE_NODES)
> > -			mpol_relative_nodemask(&nsc->mask2, nodes, &nsc->mask1);
> > -		else
> > -			nodes_and(nsc->mask2, *nodes, nsc->mask1);
> >  
> > -		if (mpol_store_user_nodemask(pol))
> > -			pol->w.user_nodemask = *nodes;
> > -		else
> > -			pol->w.cpuset_mems_allowed =
> > -						cpuset_current_mems_allowed;
> > -	}
> > +	if (pol->flags & MPOL_F_RELATIVE_NODES)
> > +		mpol_relative_nodemask(&nsc->mask2, nodes, &nsc->mask1);
> > +	else
> > +		nodes_and(nsc->mask2, *nodes, nsc->mask1);
> 
> Maybe I've just got lost here but why don't you need to check for the
> local policy anymore? mpol_new will take care of the MPOL_PREFERRED &&
> nodes_empty special but why do we want/need all this for a local policy
> at all?
 
You are right that 'local' policy doesn't need this, it should just
return in the early port of this function, like 'default' policy, which
can remove the useless nop mpol_new_local().

> >  
> > -	if (nodes)
> > -		ret = mpol_ops[pol->mode].create(pol, &nsc->mask2);
> > +	if (mpol_store_user_nodemask(pol))
> > +		pol->w.user_nodemask = *nodes;
> >  	else
> > -		ret = mpol_ops[pol->mode].create(pol, NULL);
> > +		pol->w.cpuset_mems_allowed =
> > +					cpuset_current_mems_allowed;
> 
> please use a single line. This is just harder to read. You will cross
> the line limit but readability should be preferred here.
 
Will change.

Thanks,
Feng

> [...]
> 
> I haven't spotted anything else.
> -- 
> Michal Hocko
> SUSE Labs