Hello, Glauber. On Mon, Oct 01, 2012 at 12:45:11PM +0400, Glauber Costa wrote: > > where kmemcg_slab_idx is updated from sched notifier (or maybe add and > > use current->kmemcg_slab_idx?). You would still need __GFP_* and > > in_interrupt() tests but current->mm and PF_KTHREAD tests can be > > rolled into index selection. > > How big would this array be? there can be a lot more kmem_caches than > there are memcgs. That is why it is done from memcg side. The total number of memcgs are pretty limited due to the ID thing, right? And kmemcg is only applied to subset of caches. I don't think the array size would be a problem in terms of memory overhead, would it? If so, RCU synchronize and dynamically grow them? 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>