Messages in this thread | | | Date | Fri, 7 Feb 2014 16:28:49 +0100 | From | Michal Hocko <> | Subject | Re: [PATCH] cgroup: use an ordered workqueue for cgroup destruction |
| |
On Fri 07-02-14 10:13:41, Tejun Heo wrote: > Hello, Michal. > > On Fri, Feb 07, 2014 at 03:37:40PM +0100, Michal Hocko wrote: > > Hmm, this is a bit tricky. We cannot use memcg iterators to reach > > children because css_tryget would fail on them. We can use cgroup > > iterators instead, alright, and reparent pages from leafs but this all > > sounds like a lot of complications. > > Hmmm... I think we're talking past each other here. Why would the > parent need to reach down to the children? Just bail out if it can't > make things down to zero and let the child when it finishes its own > cleaning walk up the tree propagating changes. ->parent is always > accessible. Would that be complicated too?
This would be basically the option #2 bellow.
> > Another option would be weakening css_offline reparenting and do not > > insist on having 0 charges. We want to get rid of as many charges as > > possible but do not need to have all of them gone > > (http://marc.info/?l=linux-kernel&m=139161412932193&w=2). The last part > > would be reparenting to the upmost parent which is still online. > > > > I guess this is implementable but I would prefer Hugh's fix for now and > > for stable. > > Yeah, for -stable, I think Hugh's patch is good but I really don't > want to keep it long term.
Based on our recent discussion regarding css_offline semantic we want to do some changes in that area. I thought we would simply update comments but considering this report css_offline needs some changes as well. I will look at it. The idea is to split mem_cgroup_reparent_charges into two parts. The core one which drains LRUs and would be called from mem_cgroup_css_offline and one which loops until all charges are gone for mem_cgroup_css_free. mem_cgroup_move_parent will need an update as well. It would have to go up the hierarchy to the first alive parent.
-- Michal Hocko SUSE Labs
| |