On Tue 04-12-12 12:05:21, Glauber Costa wrote: > On 12/03/2012 09:32 PM, Michal Hocko wrote: > > On Fri 30-11-12 17:31:25, Glauber Costa wrote: > >> Although there is arguably some value in doing this per se, the main > >> goal of this patch is to make room for the locking changes to come. > >> > >> With all the value assignment from parent happening in a context where > >> our iterators can already be used, we can safely lock against value > >> change in some key values like use_hierarchy, without resorting to the > >> cgroup core at all. > > > > I am sorry but I really do not get why online_css callback is more > > appropriate. Quite contrary. With this change iterators can see a group > > which is not fully initialized which calls for a problem (even though it > > is not one yet). > > But it should be extremely easy to protect against this. It is just a > matter of not returning online css in the iterator: then we'll never see > them until they are online. This also sounds a lot more correct than > returning allocated css. Yes but... Look at your other patch which relies on iterator when counting children to find out if there is any available. > > Could you be more specific why we cannot keep the initialization in > > mem_cgroup_css_alloc? We can lock there as well, no? > > > Because we need to parent value of things like use_hierarchy and > oom_control not to change after it was copied to a child. > > If we do it in css_alloc, the iterators won't be working yet - nor will > cgrp->children list, for that matter - and we will risk a situation > where another thread thinks no children exist, and flips use_hierarchy > to 1 (or oom_control, etc), right after the children already got the > value of 0. You are right. I must have been blind yesterday evening. > The two other ways to solve this problem that I see, are: > > 1) lock in css_alloc and unlock in css_online, that tejun already ruled > out as too damn ugly (and I can't possibly disagree) yes, it is really ugly > 2) have an alternate indication of emptiness that is working since > css_alloc (like counting number of children). I do not think it is worth the complication. > Since I don't share your concerns about the iterator showing incomplete > memcgs - trivial to fix, if not fixed already - I deemed my approach > preferable here. Agreed. -- 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>