> > Other points related to memcg is ... > > + kernel memory accounting + per-zone-per-memcg inode/dentry caching. > Glaubler tries to account inode/dentry in kmem controller. To do that, > I think inode and dentry should be hanldled per zone, at first. IIUC, > there are > ongoing work but not merged yet. > Yes, I've already managed to post an initial version - comments appreciated. Actually, Johannes correctly pointed out to me once that memcg pressure is never per-zone, so there is no reason for us to keep per-zone information. The logic behind this is that if there is per-zone pressure, it is always global pressure; memcg can only provide go/no-go signals, and knows nothing about zones. The only reason I am actually keeping per-zone information, is to avoid keeping the inodes/dentries in two lists. Without per-zone, we would have to keep it in a nodeless memcg list, and then in a per-zone (it is actually per-node) list, and then when global pressure kicks in, follow the zone lists. This means extra 16 bytes per objects, which adds up quickly to a large memory overhead. > + overheads by memcg > Mel explained memcg's big overheads last year's MM summit. AFAIK, we > have not > made any progress with that. If someone have detailed data, please > share again... > I had a patch for that, but didn't manage to go back to it again. Jeff Liu did some extra work to handle lazy swap enablement as well, that would go all right with it. I can probably find the time to resuscitate it before the summit. We could focus on what is still missing. -- 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>