From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: containers and cgroups mini-summit @ Linux Plumbers Date: Wed, 25 Jul 2012 20:57:46 -0700 Message-ID: <877gtr6uo5.fsf@xmission.com> References: <4FFDF321.4030103@openvz.org> <500FD022.6000608@parallels.com> Mime-Version: 1.0 Return-path: In-Reply-To: <500FD022.6000608-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> (Glauber Costa's message of "Wed, 25 Jul 2012 14:53:22 +0400") Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Glauber Costa Cc: Kir Kolyshkin , Serge Hallyn , Frederic Weisbecker , Daniel Lezcano , Johannes Weiner , Tejun Heo , Rohit Seth , Greg Thelen , Balbir Singh , Dhaval Giani , KAMEZAWA Hiroyuki , Paul Turner , Tim Hockin , Suleiman Souhlal , Dave Kleikamp , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, James Bottomley , Pavel Emelyanov , Maxim Patlasov Glauber Costa writes: > I just came up with the following preliminary list of sessions: > > http://wiki.linuxplumbersconf.org/2012:containers > > Since people mostly said what they wanted to talk about, but without > extensive descriptions, I took the liberty of coming up with a small > text for each in the blueprints. If you believe this is inaccurate, or > would like to see it extended (although I personally don't see the point > about going into very formal and deep details here), just let me know > and I will edit it. > > This is all still subject to change. Something that just came up recently and worth looking at if it hasn't already be resolved. The network namespace, the user namespace, and the memory control group are not meshing well. In particular we need some additional checks for an unprivileged user who can set tcp_mem. If you are the creator of a network namespace you should at least be able to set the values down. I don't know at all about increasing the amount of memory consumed by the tcp stack. The non-nesting nature of memory control groups with respect to the network stack also seems very bizarre. Another old issue is that unless I have missed something control groups are still broken for generic use in containers. Does anyone care? Are there any plans on fixing this issue? Eric