On 4/6/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
Well, it's less ugly than resetting pointer but it's worse from
performance POV. See, we have an if (xxx) that is true only once
during system lifetime. This is not that good...
Adding an extra comparison in the container creation path
On Wed, Apr 04, 2007 at 07:57:40PM -0700, Paul Menage wrote:
Firstly, this is not a unique problem introduced by using -nsproxy.
Secondly we have discussed this to some extent before
(http://lkml.org/lkml/2007/2/13/122). Essentially if we see zero tasks
sharing a resource object pointed to by
Paul Menage wrote:
On 4/4/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
Paul Menage wrote:
On 4/3/07, Kirill Korotaev [EMAIL PROTECTED] wrote:
Sounds reasonable.
Pavel is preparing new RSS patches on top of your patches
which take into account other comments and Andrew objections.
Can
Paul Menage wrote:
On 4/5/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
That sort of implies that we need to split the container fork
mechanism up into two parts, one early to add the refcount to the
parent's container_group, and one late to handle the callbacks if
desired. But that should
On 4/5/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
If the container directory were to have no refcount on the nsproxy, so
the initial refcount was 0,
No it should be 1.
mkdir H1/foo
rcfs_create()
ns = dup_namespaces(parent);
On Wed, Apr 04, 2007 at 11:57:18AM -0700, Paul Menage wrote:
Very true. That's a bug and can be rectified. Atm however in my patch
stack, I have dropped this whole find_nsproxy() and instead create a new
nsproxy whenever tasks move ..Not the best I agree on long run.
Or even short term, I
On Thu, Apr 05, 2007 at 10:27:52PM +0530, Srivatsa Vaddagiri wrote:
Ok ..by posting rcfs patches, I didn't mean to introduce a yours and
mine rift ..honestly. In fact you would notice that they have your
(sole) copyright still on them! It took me just two days to convert over the
patches to
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the
Paul Menage wrote:
On 4/3/07, Kirill Korotaev [EMAIL PROTECTED] wrote:
Sounds reasonable.
Pavel is preparing new RSS patches on top of your patches
which take into account other comments and Andrew objections.
Can we cooperate to send it altogher then?
Sure. Do you want to send me any
On Wed, Apr 04, 2007 at 10:56:43PM +0530, Srivatsa Vaddagiri wrote:
I think the null grouping as defined so far is very fuzzy ..How would
the kernel use this grouping, which would require reserving N pointers
in 'struct container_group'/'struct nsproxy'?
aside from needing to support 'cat
Next time I have a moment I will try and take a closer look. However
currently these approaches feel like there is some unholy coupling going
on between different things.
In addition there appear to be some weird assumptions (an array with
one member per task_struct) in the group. The pid
On 4/4/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
In addition there appear to be some weird assumptions (an array with
one member per task_struct) in the group. The pid limit allows
us millions of task_structs if the user wants it. A several megabyte
array sounds like a completely
On 4/4/07, Paul Menage [EMAIL PROTECTED] wrote:
The current code creates such arrays when it needs an atomic snapshot
of the set of tasks in the container (e.g. for reporting them to
userspace or updating the mempolicies of all the tasks in the case of
cpusets). It may be possible to do it by
On 4/4/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
- how do you handle additional reference counts on subsystems? E.g.
beancounters wants to be able to associate each file with the
container that owns it. You need to be able to lock out subsystems
from taking new reference counts on an
On Mon, Apr 02, 2007 at 12:02:35PM -0600, Eric W. Biederman wrote:
If we loose directories, then we don't have a way to manage the
task-group it represents thr' the filesystem interface, so I consider
that bad. As we agree, this will not be an issue if initrd
mounts the ns hierarchy
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Srivatsa Vaddagiri [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 09:09:39AM -0500, Serge E. Hallyn wrote:
Losing the directory isn't a big deal though. And both unsharing a
namespace (which causes a ns_container_clone) and mounting the
On 4/3/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
But frankly I don't know where we stand right now wrt the containers
patches. Do most people want to go with Vatsa's latest version moving
containers into nsproxy? Has any other development been going on?
Paul, have you made any updates?
On Tue, Apr 03, 2007 at 10:32:20AM -0500, Serge E. Hallyn wrote:
But frankly I don't know where we stand right now wrt the containers
patches. Do most people want to go with Vatsa's latest version moving
containers into nsproxy?
Has any other development been going on?
I have another
On Tue, Apr 03, 2007 at 08:45:37AM -0700, Paul Menage wrote:
Whilst I've got no objection in general to using nsproxy rather than
the container_group object that I introduced in my latest patches, I
think that Vatsa's approach of losing the general container object is
flawed, since it loses
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 08:45:37AM -0700, Paul Menage wrote:
Whilst I've got no objection in general to using nsproxy rather than
the container_group object that I introduced in my latest patches,
So are you saying lets (re-)use
Quoting Paul Menage ([EMAIL PROTECTED]):
On 4/3/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
But frankly I don't know where we stand right now wrt the containers
patches. Do most people want to go with Vatsa's latest version moving
containers into nsproxy? Has any other development been
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 09:52:35AM -0700, Paul Menage wrote:
I'm not saying let's use nsproxy - I'm not yet convinced that the
lifetime/mutation/correlation rate of a pointer in an nsproxy is
likely to be the same as for a container
On Tue, Apr 03, 2007 at 10:10:35AM -0700, Paul Menage wrote:
Agreed. So I'm not saying it's fundamentally a bad idea - just that
merging container_group and nsproxy is a fairly simple space
optimization that could easily be done later.
IMHO, if we agree that space optimization is important,
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 10:10:35AM -0700, Paul Menage wrote:
Agreed. So I'm not saying it's fundamentally a bad idea - just that
merging container_group and nsproxy is a fairly simple space
optimization that could easily be done later.
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Hmm no .. I currently have nsproxy having just M additional pointers, where
M is the maximum number of resource controllers and a single dentry
pointer.
So how do you implement something like the /proc/PID/container info
file in my
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
(Or more generally, tell which container a task is
in for a given hierarchy?)
Why is the hierarchy bit important here? Usually controllers need to
know tell me what cpuset this task belongs to, which is answered
by
On Tue, Apr 03, 2007 at 10:49:49AM -0700, Paul Menage wrote:
Why is the hierarchy bit important here? Usually controllers need to
know tell me what cpuset this task belongs to, which is answered
by tsk-nsproxy-ctlr_data[CPUSET_ID].
I was thinking of queries from userspace.
User space
vatsa wrote:
User space queries like what is the cpuset to which this task belongs,
where the answer needs to be something of the form /dev/cpuset/C1?
I think that answer should be of the form /C1, and not include the
cpuset file system mount point ... though for the purposes of the
present
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the above mail didnt make it into lkml (maybe it
exceeded the
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
+int ns_container_clone(struct task_struct *tsk)
+{
+ return container_clone(tsk, ns_subsys);
+}
This function is a no-op if ns hierarchy is not mounted at this point.
On Mon, Apr 02, 2007 at 09:09:39AM -0500, Serge E. Hallyn wrote:
Losing the directory isn't a big deal though. And both unsharing a
namespace (which causes a ns_container_clone) and mounting the hierarchy
are done by userspace, so if for some installation it is a big deal,
the init scripts on
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
+int ns_container_clone(struct task_struct *tsk)
+{
+ return container_clone(tsk, ns_subsys);
+}
This function is a no-op if ns hierarchy is not mounted at this point.
This would mean that we will miss out on some
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Sat, Mar 24, 2007 at 10:35:37AM +0530, Srivatsa Vaddagiri wrote:
+static int ns_create(struct container_subsys *ss, struct container *cont)
+{
+ struct nscont *ns;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
+/*
+ * Rules: you can only create a container if
+ * 1. you are capable(CAP_SYS_ADMIN)
+ * 2. the target container is a descendant of your own container
+ */
On Sat, Mar 24, 2007 at 10:35:37AM +0530, Srivatsa Vaddagiri wrote:
+static int ns_create(struct container_subsys *ss, struct container *cont)
+{
+ struct nscont *ns;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
Does this check break existing namespace semantics
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
+/*
+ * Rules: you can only create a container if
+ * 1. you are capable(CAP_SYS_ADMIN)
+ * 2. the target container is a descendant of your own container
+ */
+static int ns_create(struct container_subsys *ss, struct
36 matches
Mail list logo
