[lkml]   [2006]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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:

    | | |
    -----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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-01 22:09    [W:0.021 / U:11.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site