On Mon 10-06-13 12:54:26, Tejun Heo wrote: > Hello, Michal. > > On Mon, Jun 10, 2013 at 10:02:08AM +0200, Michal Hocko wrote: > > Sure a next visit on the same root subtree (same node, zone and prio) > > would css_put it but what if that root goes away itself. Still fixable, > > if every group checks its own cached iters and css_put everybody but > > that is even uglier. So doing the up-the-hierarchy cleanup in RCU > > callback is much easier. > > Ooh, right, we don't need cleanup of the cached cursors on destruction > if we get this correct - especially if we make cursors point to the > next cgroup to visit as self is always the first one to visit. You would need to pin the next-to-visit memcg as well, so you need a cleanup on the removal. > Yeah, if we can do away with that, doing that way is definitely > better. The only advantage I can see from next-to-visit caching is that the destruction path can reuse __mem_cgroup_iter_next unlike last_visited which would need to develop a code to get the previous member. Maybe it is worth a try. -- 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
