lkml.org 
[lkml]   [2006]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 7/7] uts namespaces: Implement CLONE_NEWUTS flag
    Quoting Andi Kleen (ak@suse.de):
    > On Tuesday 02 May 2006 19:20, Serge E. Hallyn wrote:
    > > Quoting Andi Kleen (ak@suse.de):
    > > > Have a proxy structure which has pointers to the many name spaces and a bit
    > > > mask for "namespace X is different".
    > >
    > > different from what?
    >
    > From the parent.

    ...

    > > Oh, you mean in case we want to allow cloning a namespace outside of
    > > fork *without* cloning the nsproxy struct?
    >
    > Basically every time any name space changes you need a new nsproxy.

    But, either the nsproxy is shared between tasks and you need to copy
    youself a new one as soon as any ns changes, or it is not shared, and
    you don't need that info at all (just make the change in the nsproxy
    immediately)

    What am I missing?

    Should we talk about this on irc someplace? Perhaps drag in Eric as
    well?

    > > > This structure would be reference
    > > > counted. task_struct has a single pointer to it.
    > >
    > > If it is reference counted, that implies it is shared between some
    > > processes. But namespace pointers themselves are shared between some of
    > > these nsproxy's. The lifetime mgmt here is one reason I haven't tried a
    > > patch to do this.
    >
    > The livetime management is no different from having individual pointers.

    That's true if we have one nsproxy per process or thread, which I didn't
    think was the case. Are you saying not to share nsproxy's among
    processes which share all namespaces?

    > > > With many name spaces you would have smaller task_struct, less cache
    > > > foot print, better cache use of task_struct because slab cache colouring
    > > > will still work etc.
    > >
    > > I suppose we could run some performance tests with some dummy namespace
    > > pointers? 9 void *'s directly in the task struct, and the same inside a
    > > refcounted container struct. The results might add some urgency to
    > > implementing the struct nsproxy.
    >
    > Not sure you'll notice too much difference on the beginning. I am just

    9 void*'s is probably more than we'll need, though, so it's not "the
    beginning". Eric previously mentioned uts, sysvipc, net, pid, and uid,
    to which we might add proc, sysctl, and signals, though those are
    probably just implied through the others.

    What others do you see us needing?

    If the number were more likely to be 50, then in the above experiment
    use 50 instead - the point was to see the performance implications
    without implementing the namespaces first.

    Anyway I guess I'll go ahead and queue up some tests.

    > the opinion memory/cache bloat needs to be attacked at the root, not
    > when it's too late.

    -serge
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-03 18:14    [W:0.035 / U:212.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site