[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070307215919.GA2110@sergelap.austin.ibm.com>
Date: Wed, 7 Mar 2007 15:59:19 -0600
From: "Serge E. Hallyn" <serue@...ibm.com>
To: Paul Menage <menage@...gle.com>
Cc: "Serge E. Hallyn" <serue@...ibm.com>,
Srivatsa Vaddagiri <vatsa@...ibm.com>, ebiederm@...ssion.com,
sam@...ain.net, akpm@...ux-foundation.org, pj@....com, dev@...ru,
xemul@...ru, containers@...ts.osdl.org, winget@...gle.com,
ckrm-tech@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!
Quoting Paul Menage (menage@...gle.com):
> On 3/7/07, Serge E. Hallyn <serue@...ibm.com> wrote:
> >
> >All that being said, if it were going to save space without overly
> >complicating things I'm actually not opposed to using nsproxy, but it
>
> If space-saving is the main issue, then the latest version of my
Space saving was the only reason for nsproxy to exist.
Now of course it also provides the teensiest reduction in # instructions
since every clone results in just one reference count inc for the
nsproxy rather than one for each namespace.
> containers patches uses just a single pointer in the task_struct, and
> all tasks in the same set of containers (across all hierarchies) will
> share a single container_group object, which holds the actual pointers
> to container state.
Yes, that's why this consolidation doesn't make sense to me.
Especially considering again that we will now have nsproxies pointing to
containers pointing to... nsproxies.
> Effectively, container_group is to container as nsproxy is to namespace.
>
> Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists