lkml.org 
[lkml]   [2006]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/4] Virtualization/containers: introduction
    From
    Date
    Hubertus Franke <frankeh@watson.ibm.com> writes:
    >
    > Agreed.. here are some issued we learned from other projects that had
    > similar interception points.
    >
    > Having a central umbrella object (let's stick to the name container)
    > is useful, but being the only object through which every access has to
    > pass may have drawbacks..
    >
    > task->container->pspace->pidmap[offset].page implies potential
    > cachemisses etc.
    >
    > If overhead becomes too large, then we can stick (cache) the pointer
    > additionally in the task struct. But ofcourse that should be carefully
    > examined on a per subsystem base...

    Ok. After talking with the vserver guys on IRC. I think grasp the
    importance. The key feature is to have a place to put limits and the
    like for your entire container. Look at all of the non-signal stuff
    in struct signal for an example. The nested namespaces seem to
    be just an implementation detail.

    For OpenVZ having the other namespaces nested may have some
    importance. I haven't gotten their yet.

    The task->container->pspace->.... thing feels very awkward to me,
    and feels like it increases our chance getting a cache miss.

    So I support the concept of a place to put all of the odd little
    things like rlimits for containers. But I would like to flatten
    it in the task_struct if we can.


    Eric
    -
    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-02-08 06:08    [W:4.057 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site