On Tue 11-06-13 00:44:04, Tejun Heo wrote: > 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. Ahh, sorry I have misread your reply then. You are right that caching the next-to-visit would keep its own cache clean. > 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. Right. > 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"? If you replace cached memcg by a new (non-NULL) one then all the parents up the hierarchy can reuse the same replacement and do not have to search again. -- 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>