On Tue, Jun 11, 2013 at 09:27:43AM +0200, Michal Hocko wrote: > . > . > . > 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? I don't think we're talking about the same thing. I wasn't talking about skipping walking up the hierarchy (differently depending on use_hierarchy of course) when E is removed. I was talking about skipped cleaning E's cache when removing E as it's guaranteed to be empty by then. The difference between caching the last and next one is that if we put the last one in the cache, E's cache could be pointing to itself and needs to be scanned. Not a big difference either way but if you combine that with the need for special rewinding which will basically come down to traversing the sibling list again, pointing to the next entry is just easier. Anyways, I think we're getting too deep into details but one more thing, what do you mean by "non-NULL new cache"? Thanks. -- tejun -- 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>