lkml.org 
[lkml]   [2006]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
    On Mon, Oct 30, 2006 at 12:47:59PM -0800, Paul Menage wrote:
    > On 10/30/06, Paul Jackson <pj@sgi.com> wrote:
    > >
    > >In other words you are recommending delivering a system that internally
    > >tracks separate hierarchies for each resource control entity, but where
    > >the user can conveniently overlap some of these hierarchies and deal
    > >with them as a single hierarchy.
    >
    > More or less. More concretely:
    >
    > - there is a single hierarchy of process containers
    > - each process is a member of exactly one process container
    >
    > - for each resource controller, there's a hierarchy of resource "nodes"
    > - each process container is associated with exactly one resource node
    > of each type
    >
    > - by default, the process container hierarchy and the resource node
    > hierarchies are isomorphic, but that can be controlled by userspace.

    For the case where resource node hierarchy is different from process
    container hierarchy, I am trying to make sense of "why do we need to
    maintain two hierarchies" - one the actual hierarchy used for resource
    control purpose, another the process container hierarchy. What purpose
    does maintaining the process container hierarchy (in addition to the
    resource controller hierarchy) solve?

    I am thinking we can avoid maintaining these two hierarchies, by
    something on these lines:

    mkdir /dev/cpu
    mount -t container -ocpu container /dev/cpu

    -> Represents a hierarchy for cpu control purpose.

    tsk->cpurc = represent the node in the cpu
    controller hierarchy. Also maintains
    resource allocation information for
    this node.

    tsk->cpurc->parent = parent node.

    mkdir /dev/mem
    mount -t container -omem container /dev/mem

    -> Represents a hierarchy for mem control purpose.

    tsk->memrc = represent the node in the mem
    controller hierarchy. Also maintains
    resource allocation information for
    this node.

    tsk->memrc->parent = parent node.


    mkdir /dev/containers
    mount -t container -ocontainer container /dev/container

    -> Represents a (mostly flat?) hierarchy for the real
    container (virtualization) purpose.

    tsk->container = represent the node in the container
    hierarchy. Also maintains relavant
    container information for this node.

    tsk->container->parent = parent node.


    I suspect this may simplify the "container" filesystem, since it doesnt
    have to track multiple hierarchies at the same time, and improve lock
    contention too (modifying the cpu controller hierarchy can take a different
    lock than the mem controller hierarchy).

    --
    Regards,
    vatsa
    -
    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-10-31 12:53    [W:4.161 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site