On Thu, Mar 31, 2011 at 01:23:13PM +0400, Pavel Emelyanov wrote: > > 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. Sounds good. > > > a) Kernel memory accounting. > > This one is very interesting to me. I expected someone would have been interested into that... > > 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. Ok, so I've added you to the second half of "what's next". -- 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>