[Devel] Re: [PATCH] c/r: Add UTS support (v4)

Oren Laadan orenl at cs.columbia.edu
Fri Mar 20 14:58:15 PDT 2009



Dave Hansen wrote:
> On Fri, 2009-03-20 at 17:26 -0400, Oren Laadan wrote:
>> Dave Hansen wrote:
>>> On Fri, 2009-03-20 at 16:48 -0400, Oren Laadan wrote:
>>>> Does that scale well with many (1000's) of tasks ?
>>>>
>>>> (The motivation to expose 'nsproxy_objref' to user space was to allow
>>>> user-space to decide on a sequence of clones/unshared that will create
>>>> an equivalent process tree with space-efficient nsproxy's).
>>> OK, so you're saying that there's no way for userspace to tell that a
>>> set of tasks share an nsproxy other than exporting that nsproxy?
>> I don't think so. Maybe the namespaces people know better.
> 
> Please go look at the code.


Heheh .. read: "I don't think so" as in "I don't think tasks in user
space can tell whether or not they share an nsproxy in the kernel."

(and the corollary follows ...)

> 
> Two processes share an nsproxy (or *can* share an nsproxy) when all of
> the namespace pointers are the same.  After allocation and
> initialization, we basically don't ever write to the nsproxy.  We just
> hook it into a task and run with it.
> 
> If anything ever unshares one of the nsproxy namespaces, before writing
> to it we *first* create a new nsproxy which is a copy of the old one.
> 
> We basically open-code copy-on-write semantics for the nsproxy.
> 
> This means that it is safe for any two tasks that share all of the
> pointers in the nsproxy to share an nsproxy itself.
> 
> -- Dave

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list