On Mon 16-12-13 11:35:30, Tejun Heo wrote: > On Mon, Dec 16, 2013 at 11:40:42AM +0100, Michal Hocko wrote: > > > How would this work? The task which pushed the memory to the swap is > > > still alive (living in a different group) and the swap will be there > > > after the last reference to css as well. > > > > Or did you mean to get css reference in swap_cgroup_record and release > > it in __mem_cgroup_try_charge_swapin? > > > > That would prevent the warning (assuming idr_remove would move to > > css_free[1]) but I am not sure this is the right thing to do. memsw charges > > will be accounted to the parent already (assuming there is one) without > > anybody to uncharge them because all uncharges would fallback to the > > root memcg after css_offline. > > > > Hugh's approach seems much better. > > Hmmm... I think it's reasonable for css's to expect cgrp->id to not be > recycled before all css refs are gone. If Hugh's patches are > something desriable independent of cgrp->id issues, great, but, if > not, let's first try to get it right from cgroup core. Is it enough > for css_from_id() to return NULL after offline until all refs are > gone? That should be an easy fix. I have to think about it some more (the brain is not working anymore today). But what we really need is that nobody gets the same id while the css is alive. So css_from_id returning NULL doesn't seem to be enough. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
