On Mon 21-01-13 12:41:24, Glauber Costa wrote: > On 01/21/2013 12:34 PM, Michal Hocko wrote: [...] > > If you really insist on not using > > children directly then do something like: > > struct cgroup *pos; > > > > if (!memcg->use_hierarchy) > > cgroup_for_each_child(pos, memcg->css.cgroup) > > return true; > > > > return false; > > > I don't oppose that. OK, I guess I could live with that ;) > > This still has an issue that a change (e.g. vm_swappiness) that requires > > this check will fail even though the child creation fails after it is > > made visible (e.g. during css_online). > > > Is it a problem ? I thought you were considering this a problem. Quoting from patch 3/7 " > This calls for troubles and I do not think the win you get is really > worth it. All it gives you is basically that you can change an > inheritable attribute while your child is between css_alloc and > css_online and so your attribute change doesn't fail if the child > creation fails between those two. Is this the case you want to > handle? Does it really even matter? I think it matters a lot. Aside from the before vs after discussion to which I've already conceded, without this protection we can't guarantee that we won't end up with an inconsistent value of the tunables between parent and child. " Just to make it clear. I do not see this failure as a big problem. We can fix it by adding an Online check later if somebody complains. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>