lkml.org 
[lkml]   [2006]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
    On Wed, 1 Nov 2006, Srivatsa Vaddagiri wrote:

    > This would forces all tasks in container A to belong to the same mem/io ctlr
    > groups. What if that is not desired? How would we achieve something like
    > this:
    >
    > tasks (m) should belong to mem ctlr group D,
    > tasks (n, o) should belong to mem ctlr group E
    > tasks (m, n, o) should belong to i/o ctlr group G
    >

    With the example you would need to place task m in one container called
    A_m and tasks n and o in another container called A_n,o. Then join A_m to
    D, A_n,o to E, and both to G.

    I agree that this doesn't appear to be very easy to setup by the sysadmin
    or any automated means. But in terms of the kernel, each of these tasks
    would have a pointer back to its container and that container would point
    to its assigned resource controller. So it's still a double dereference
    to access the controller from any task_struct.

    So if we proposed a hierarchy of containers, we could have the following:

    ----------A----------
    | | |
    -----B----- m -----C------
    | | |
    n -----D----- o
    | |
    p q

    So instead we make the requirement that only one container can be attached
    to any given controller. So if container A is attached to a disk I/O
    controller, for example, then it includes all processes. If D is attached
    to it instead, only p and q are affected by its constraints.

    This would be possible by adding a field to the struct container that
    would point to its parent cpu, net, mem, etc. container or NULL if it is
    itself.

    The difference:

    Single-level container hierarchy

    struct task_struct {
    ...
    struct container *my_container;
    }
    struct container {
    ...
    struct controller *my_cpu_controller;
    struct controller *my_mem_controller;
    }

    Multi-level container hierarchy

    struct task_struct {
    ...
    struct container *my_container;
    }
    struct container {
    ...
    /* Root containers, NULL if itself */
    struct container *my_cpu_root_container;
    struct container *my_mem_root_container;
    /* Controllers, NULL if has parent */
    struct controller *my_cpu_controller;
    struct controller *my_mem_controller;
    }

    This eliminates the need to put a pointer to each resource controller
    within each task_struct.

    > (this example breaks the required condition/assumption that a task belong to
    > exactly only one process container).
    >

    Yes, and that was the requirement that the above example was based upon.

    David
    -
    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-11-01 22:09    [W:0.024 / U:92.204 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site