Re: [PATCH 1/2] memcg: reparent charges of children before processing parent

[Tejun Heo]

Hello,

On Thu, Feb 13, 2014 at 04:27:45PM +0100, Michal Hocko wrote:
> > Further testing showed that an ordered workqueue for cgroup_destroy_wq
> > is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched
> > stage on the way can mess up the order before reaching the workqueue.
> 
> This whole code path is so complicated by different types of delayed
> work that I am not wondering that we have missed that :/

Yeah, I know.  Good part of the complexity comes from RCU -> wq
bouncing.  I wonder whether we just should bite the bullet and add
something along the line of call_rcu_work().  The other part is percpu
ref shutdown.  For me that part is easier to swallow, as the benefits
are quite clear.

> > Instead, when offlining a memcg, call mem_cgroup_reparent_charges() on
> > all its children (and grandchildren, in the correct order) to have their
> > charges reparented first.
> 
> That is basically what I was suggesting
> http://marc.info/?l=linux-mm&m=139178386407184&w=2 as #1 option. I
> cannot say I would like it and I think that reparenting LRUs in
> css_offline and then reparent the remaining charges from css_free is a
> better solution but let's keep this for later.

I'm kinda wishing the reparenting things works out.  Even if that
involves a bit of overhead at offline, I think it'd be worthwhile to
be able to follow the same object lifetime rules as other controllers,
as long as the overhead is reasonable.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/