Hello, On Mon, Aug 31, 2015 at 06:18:14PM +0300, Vladimir Davydov wrote: > We have to be cautious about placing memcg_charge in slab/slub. To > understand why, consider SLAB case, which first tries to allocate from > all nodes in the order of preference w/o __GFP_WAIT and only if it fails > falls back on an allocation from any node w/ __GFP_WAIT. This is its > internal algorithm. If we blindly put memcg_charge to alloc_slab method, > then, when we are near the memcg limit, we will go over all NUMA nodes > in vain, then finally fall back to __GFP_WAIT allocation, which will get > a slab from a random node. Not only we do more work than necessary due > to walking over all NUMA nodes for nothing, but we also break SLAB > internal logic! And you just can't fix it in memcg, because memcg knows > nothing about the internal logic of SLAB, how it handles NUMA nodes. > > SLUB has a different problem. It tries to avoid high-order allocations > if there is a risk of invoking costly memory compactor. It has nothing > to do with memcg, because memcg does not care if the charge is for a > high order page or not. Maybe I'm missing something but aren't both issues caused by memcg failing to provide headroom for NOWAIT allocations when the consumption gets close to the max limit? Regardless of the specific usage, !__GFP_WAIT means "give me memory if it can be spared w/o inducing direct time-consuming maintenance work" and the contract around it is that such requests will mostly succeed under nominal conditions. Also, slab/slub might not stay as the only user of try_charge(). I still think solving this from memcg side is the right direction. 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>