Quoting Tejun Heo (t...@kernel.org):
> On Wed, Feb 11, 2015 at 05:00:23PM +0100, Serge E. Hallyn wrote:
> > We absolutely would love to use cgroup namespaces to run older
> > userspace in containers. I don't know that it's actually possible
> > to do both that and use unified hierarchy at the same
On Wed, Feb 11, 2015 at 05:00:23PM +0100, Serge E. Hallyn wrote:
> We absolutely would love to use cgroup namespaces to run older
> userspace in containers. I don't know that it's actually possible
> to do both that and use unified hierarchy at the same time though,
> which is unfortunate. So an
Quoting Tejun Heo (t...@kernel.org):
> Hey,
>
> On Tue, Feb 10, 2015 at 11:02:40PM -0600, Eric W. Biederman wrote:
> > A slightly off topic comment, for where this thread has gone but
> > relevant if we are talking about cgroup namespaces.
> >
> > If don't implement compatibility with existing us
Hey,
On Wed, Feb 11, 2015 at 12:29:20AM -0600, Eric W. Biederman wrote:
> In general namespaces are not necessary if your scope of names
> already has hierarchy. Which means that new interfaces can almost
> always be designed in such a way that you can support containers without
> needing to add
Tejun Heo writes:
> Hey,
>
> On Tue, Feb 10, 2015 at 11:02:40PM -0600, Eric W. Biederman wrote:
>> A slightly off topic comment, for where this thread has gone but
>> relevant if we are talking about cgroup namespaces.
>>
>> If don't implement compatibility with existing userspace, they get a
>>
Hey,
On Tue, Feb 10, 2015 at 11:02:40PM -0600, Eric W. Biederman wrote:
> A slightly off topic comment, for where this thread has gone but
> relevant if we are talking about cgroup namespaces.
>
> If don't implement compatibility with existing userspace, they get a
> nack. A backwards-incompatib
Hello,
On Wed, Feb 11, 2015 at 05:29:42AM +0100, Serge E. Hallyn wrote:
> > There shouldn't be a "freezer" cgroup. The processes are categorized
> > according to their logical structure and controllers are applied to
> > the hierarchy as necessary.
>
> But there can well be cgroups for which onl
A slightly off topic comment, for where this thread has gone but
relevant if we are talking about cgroup namespaces.
If don't implement compatibility with existing userspace, they get a
nack. A backwards-incompatible change should figure out how to remove
the need for any namespaces.
Because th
Quoting Tejun Heo (t...@kernel.org):
> On Wed, Feb 11, 2015 at 04:46:16AM +0100, Serge E. Hallyn wrote:
> > 1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used
> > to start with 1. I expect many userspace parsers to be broken by this.
>
> This is intentional. The unified hi
On Wed, Feb 11, 2015 at 04:46:16AM +0100, Serge E. Hallyn wrote:
> 1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used
> to start with 1. I expect many userspace parsers to be broken by this.
This is intentional. The unified hierarchy will always have the
hierarchy number z
Quoting Tejun Heo (t...@kernel.org):
> On Wed, Jan 07, 2015 at 05:27:38PM -0600, Eric W. Biederman wrote:
> > >> The -o SUBSYS option doesn't exist. Jesus, at least get yourself
> > >> familiar with the basics before claiming random stuff.
> >
> > Oh let's see I got that command line option out o
On Wed, Jan 07, 2015 at 05:27:38PM -0600, Eric W. Biederman wrote:
> >> The -o SUBSYS option doesn't exist. Jesus, at least get yourself
> >> familiar with the basics before claiming random stuff.
>
> Oh let's see I got that command line option out of /proc/mounts and yes
> it works. Perhaps it
ebied...@xmission.com (Eric W. Biederman) writes:
> Tejun Heo writes:
>
>> On Wed, Jan 07, 2015 at 05:02:17PM -0600, Eric W. Biederman wrote:
>>> Ignoring namespace details for a moment. The following should be
>>> possible with a unified hierarchy. If it is not it is a show stopper
>>> of a reg
On Wed, Jan 07, 2015 at 05:09:53PM -0600, Eric W. Biederman wrote:
> I may have mistyped the manual command line configuration for specifying
> which controllers appear on a mount point does not alter my point.
Hmmm? You were talking about the old hierarchies?
> The old options to enable selecti
Tejun Heo writes:
> On Wed, Jan 07, 2015 at 05:02:17PM -0600, Eric W. Biederman wrote:
>> Ignoring namespace details for a moment. The following should be
>> possible with a unified hierarchy. If it is not it is a show stopper
>> of a regression.
>
> The -o SUBSYS option doesn't exist. Jesus, a
On Wed, Jan 07, 2015 at 05:02:17PM -0600, Eric W. Biederman wrote:
> Ignoring namespace details for a moment. The following should be
> possible with a unified hierarchy. If it is not it is a show stopper
> of a regression.
The -o SUBSYS option doesn't exist. Jesus, at least get yourself
familia
Tejun Heo writes:
> On Wed, Jan 07, 2015 at 04:14:40PM -0600, Eric W. Biederman wrote:
>> I see what you mean. If it is indeed the case than a mount of cgroupfs
>> using the unified hiearchy and can not specify which controllers are
>> present under that mount that very significant bug and prese
On Wed, Jan 07, 2015 at 04:14:40PM -0600, Eric W. Biederman wrote:
> I see what you mean. If it is indeed the case than a mount of cgroupfs
> using the unified hiearchy and can not specify which controllers are
> present under that mount that very significant bug and presents a very
> significant
"Serge E. Hallyn" writes:
>> By unified hierarchy I mean that every mount of cgroupfs has the
>> same directories with the same processes in each directory.
>
> No, my reading of Documentation/cgroups/unified-hierarchy.txt is that
> unified hierarchy means that all (sane) controllers are co-mo
Quoting Eric W. Biederman (ebied...@xmission.com):
> Richard Weinberger writes:
>
> > 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
On Wed, Jan 7, 2015 at 1:28 AM, Richard Weinberger wrote:
> 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 yo
Richard Weinberger writes:
> 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 y
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 c
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 c
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?
N
Am 06.01.2015 um 01:10 schrieb Aditya Kali:
> Since the old/default behavior is on its way out, I didn't invest time
> in fixing that. Also, some of the properties that make
> cgroup-namespace simpler are only provided by unified hierarchy (for
> example: a single root-cgroup per container).
Does
On Mon, Jan 5, 2015 at 3:53 PM, Eric W. Biederman wrote:
> Richard Weinberger writes:
>
>> Am 05.01.2015 um 23:48 schrieb Aditya Kali:
>>> On Sun, Dec 14, 2014 at 3:05 PM, Richard Weinberger wrote:
Aditya,
I gave your patch set a try but it does not work for me.
Maybe you can
Am 06.01.2015 um 00:53 schrieb Eric W. Biederman:
> Richard Weinberger writes:
>
>> Am 05.01.2015 um 23:48 schrieb Aditya Kali:
>>> On Sun, Dec 14, 2014 at 3:05 PM, Richard Weinberger wrote:
Aditya,
I gave your patch set a try but it does not work for me.
Maybe you can bring
Richard Weinberger writes:
> Am 05.01.2015 um 23:48 schrieb Aditya Kali:
>> On Sun, Dec 14, 2014 at 3:05 PM, Richard Weinberger wrote:
>>> Aditya,
>>>
>>> I gave your patch set a try but it does not work for me.
>>> Maybe you can bring some light into the issues I'm facing.
>>> Sadly I still had
Thanks for the review. I have made the suggested fixes. Regarding
relative path, please see inline.
On Fri, Dec 12, 2014 at 12:54 AM, Zefan Li wrote:
>> +In its current form, the cgroup namespaces patcheset provides following
>> +behavior:
>> +
>> +(1) The 'cgroupns-root' for a cgroup namespace i
Am 05.01.2015 um 23:48 schrieb Aditya Kali:
> On Sun, Dec 14, 2014 at 3:05 PM, Richard Weinberger wrote:
>> Aditya,
>>
>> I gave your patch set a try but it does not work for me.
>> Maybe you can bring some light into the issues I'm facing.
>> Sadly I still had no time to dig into your code.
>>
>>
On Sun, Dec 14, 2014 at 3:05 PM, Richard Weinberger wrote:
> Aditya,
>
> I gave your patch set a try but it does not work for me.
> Maybe you can bring some light into the issues I'm facing.
> Sadly I still had no time to dig into your code.
>
> Am 05.12.2014 um 02:55 schrieb Aditya Kali:
>> Signe
Aditya,
I gave your patch set a try but it does not work for me.
Maybe you can bring some light into the issues I'm facing.
Sadly I still had no time to dig into your code.
Am 05.12.2014 um 02:55 schrieb Aditya Kali:
> Signed-off-by: Aditya Kali
> ---
> Documentation/cgroups/namespace.txt | 147
> +In its current form, the cgroup namespaces patcheset provides following
> +behavior:
> +
> +(1) The 'cgroupns-root' for a cgroup namespace is the cgroup in which
> +the process calling unshare is running.
> +For ex. if a process in /batchjobs/container_id1 cgroup calls unshare,
> +cg
Signed-off-by: Aditya Kali
---
Documentation/cgroups/namespace.txt | 147
1 file changed, 147 insertions(+)
create mode 100644 Documentation/cgroups/namespace.txt
diff --git a/Documentation/cgroups/namespace.txt
b/Documentation/cgroups/namespace.txt
new fil
35 matches
Mail list logo
