On Mon 10-06-13 16:13:58, Tejun Heo wrote:
> Hey,
>
> On Mon, Jun 10, 2013 at 10:48:01PM +0200, Michal Hocko wrote:
> > > 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.
>
> But that'd be one of the descendants of the said cgroup and there can
> no descendant left when the cgroup is being removed. What am I
> missing?
.
.
.
A (cached=E)
/|\____________
/ | \
B D (cached=E) F<
/ | \
C< E G
^
removed
* D level cache - nobody left for either approach approach
* A level is
- F for next-to-visit
- C for last_visited
You have to get up the hierarchy and handle root cgroup as a special
case for !root->use_hierarchy. Once you have non-NULL new cache the it
can be propagated without a new search (which I haven't realized when
working on this approach the last time - not that it would safe some
code in the end).
Makes sense?
--
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>