On Thu, Oct 24, 2024 at 04:51:46PM GMT, Roman Gushchin wrote: > On Thu, Oct 24, 2024 at 11:14:01AM +0200, Michal Hocko wrote: > > On Wed 23-10-24 23:57:10, Shakeel Butt wrote: > > > Proceed with the complete deprecation of memcg v1's charge moving > > > feature. The deprecation warning has been in the kernel for almost two > > > years and has been ported to all stable kernel since. Now is the time to > > > fully deprecate this feature. > > > > > > Signed-off-by: Shakeel Butt <shakeel.butt@xxxxxxxxx> > > > > I fine with this move, just one detail we might need to consider > > [...] > > > @@ -606,17 +606,7 @@ static int mem_cgroup_move_charge_write(struct cgroup_subsys_state *css, > > > "Please report your usecase to linux-mm@xxxxxxxxx if you " > > > "depend on this functionality.\n"); > > > > > > - if (val & ~MOVE_MASK) > > > - return -EINVAL; > > > - > > > - /* > > > - * No kind of locking is needed in here, because ->can_attach() will > > > - * check this value once in the beginning of the process, and then carry > > > - * on with stale data. This means that changes to this value will only > > > - * affect task migrations starting after the change. > > > - */ > > > - memcg->move_charge_at_immigrate = val; > > > - return 0; > > > + return -EINVAL; > > > > Would it make more sense to -EINVAL only if val != 0? The reason being > > that some userspace might be just writing 0 here for whatever reason and > > see the failure unexpected. > > I think it's a good idea. > > Thanks! Thanks Michal and Roman for the review and I will make this change in the next version.
