On Thu, 6 Nov 2014, Vladimir Davydov wrote: > I call memcg_kmem_recharge_slab only on alloc path. Free path isn't > touched. The overhead added is one function call. The function only > reads and compares two pointers under RCU most of time. This is > comparable to the overhead introduced by memcg_kmem_get_cache, which is > called in slab_alloc/slab_alloc_node earlier. Right maybe remove those too? Things seem to be accumulating in the hot path which is bad. There is a slow path where these things can be added and also a page based even slower path for statistics keeping. The approach in SLUB is to do accounting on a slab page basis. Also memory policies are applied at page granularity not object granularity. > Anyways, if you think this is unacceptable, I don't mind dropping the > whole patch set and thinking more on how to fix this per-memcg caches > trickery. What do you think? Maybe its possible to just use slab page accounting instead of object accounting? Reduces overhead significantly. There may be some fuzz here with occasional object accounted in the wrong way (which is similar to how memory policies and other methods work) but it has been done before and works ok. -- 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>