On Sun, Apr 20, 2014 at 02:39:31PM +0400, Vladimir Davydov wrote: > * Way #2 - reap caches periodically or on vmpressure * > > We can remove the async work scheduling from kmem_cache_free completely, > and instead walk over all dead kmem caches either periodically or on > vmpressure to shrink and destroy those of them that become empty. > > That is what I had in mind when submitting the patch set titled "kmemcg: > simplify work-flow": > https://lkml.org/lkml/2014/4/18/42 > > Pros: easy to implement > Cons: instead of being destroyed asap, dead caches will hang around > until some point in time or, even worse, memory pressure condition. This would continue to pin css after cgroup destruction indefinitely, or at least for an arbitrary amount of time. To reduce the waste from such pinning, we currently have to tear down other parts of the memcg optimistically from css_offline(), which is called before the last reference disappears and out of hierarchy order, making the teardown unnecessarily complicated and error prone. So I think "easy to implement" is misleading. What we really care about is "easy to maintain", and this basically excludes any async schemes. As far as synchronous cache teardown goes, I think everything that introduces object accounting into the slab hotpaths will also be a tough sell. Personally, I would prefer the cache merging, where remaining child slab pages are moved to the parent's cache on cgroup destruction. -- 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>