From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752278AbbAFXjM (ORCPT ); Tue, 6 Jan 2015 18:39:12 -0500 Received: from a.ns.miles-group.at ([95.130.255.143]:65277 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751667AbbAFXjK (ORCPT ); Tue, 6 Jan 2015 18:39:10 -0500 Message-ID: <54AC7216.30001@nod.at> Date: Wed, 07 Jan 2015 00:39:02 +0100 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Aditya Kali CC: "Eric W. Biederman" , Tejun Heo , Li Zefan , Serge Hallyn , Andy Lutomirski , cgroups mailinglist , "linux-kernel@vger.kernel.org" , Linux API , Ingo Molnar , Linux Containers , Rohit Jnagal , Vivek Goyal Subject: Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces References: <1417744550-6461-1-git-send-email-adityakali@google.com> <1417744550-6461-9-git-send-email-adityakali@google.com> <548E17CE.8010704@nod.at> <54AB15BD.8020007@nod.at> <87lhlgpyxk.fsf@x220.int.ebiederm.org> <54AB2992.6060707@nod.at> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 07.01.2015 um 00:20 schrieb Aditya Kali: > I understand your point. But it will add some complexity to the code. > > Before trying to make it work for non-unified hierarchy cases, I would > like to get a clearer idea. > What do you expect to be mounted when you run: > container:/ # mount -t cgroup none /sys/fs/cgroup/ > from inside the container? I expect cgroupfs to behave exactly as it would in the initial namespace. Such that the container can do with it whatever it wants. systemd mounts and manages cgroups on its own. Like for CONFIG_DEVPTS_MULTIPLE_INSTANCES. If a new cgroup namespace cannot provide a clean and autonomous cgroupfs instance it is fundamentally flawed. You cannot provide a namespace mechanism which depends on the host side that much. This will also horrible break container migrations between hosts. i.e. Migrate a container from a Ubuntu host to a Fedora (systemd!) host. > Note that cgroup-namespace wont be able to change the way cgroups are > mounted .. i.e., if say cpu and cpuacct subsystems are mounted > together at a single mount-point, then we cannot mount them any other > way (inside a container or outside). This restriction exists today and > cgroup-namespaces won't change that. Why can't cgroup namespace change this? I think of cgroup namespace as a new and clean cgroupfs instance which inherits all limits from the outside. > So, If on the host we have: > root@adityakali-vm2:/sys/fs/cgroup# cat /proc/mounts | grep cgroup > tmpfs /sys/fs/cgroup tmpfs rw,relatime 0 0 > cgroup /sys/fs/cgroup/cpu cgroup rw,relatime,cpuset,cpu,cpuacct 0 0 > cgroup /sys/fs/cgroup/mem cgroup rw,relatime,memory,hugetlb 0 0 > cgroup /sys/fs/cgroup/rest cgroup > rw,relatime,devices,freezer,net_cls,blkio,perf_event,net_prio 0 0 > > And inside the container we want each subsystem to be on its own > mount-point, then it will fail. Do you think even then its useful to > support virtualizing paths for non-unified hierarchies? As I've stated above I expect from cgroup namespaces a clean and sane cgroupfs instance no matter how the outer mounts are. Thanks, //richard