Re: [Lsf] [LSF][MM] rough agenda for memcg.

[Pavel Emelyanov <xemul@parallels.com>]

>  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@kvack.org.  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@kvack.org"> email@kvack.org </a>