> b) single LRU and per memcg zone->lru_lock. > I hear zone->lru_lock contention caused by memcg is a problem on Google servers. > Okay, please show data. (I've never seen it.) > Then, we need to discuss Pros. and Cons. of current design and need to consinder > how to improve it. I think Google and Michal have their own implementation. > > Current design of double-LRU is from the 1st inclusion of memcg to the kernel. > But I don't know that discussion was there. Balbir, could you explain the reason > of this design ? Then, we can go ahead, somewhere. I would like to take part in that and describe what we've done with LRU in OpenVZ in details. > a) Kernel memory accounting. This one is very interesting to me. > f) vm_overcommit_memory should be supproted with memcg ? > (I remember there was a trial. But I think it should be done in other cgroup > as vmemory cgroup.) And this one too - I have an implementation of overcommit management in OpenVZ, I can describe one and discuss pros-n-cons. Thanks, Pavel -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>