[lkml]   [2008]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] libcg: design and plans
    Paul Menage wrote:
    > On Wed, Mar 5, 2008 at 3:07 AM, Dhaval Giani <> wrote:
    >> OK. Hmm, I've not really thought about it. At first thought, it should
    >> not be very difficult. Only thing I am not sure is the arbitrary
    >> grouping of the groups (ok, a bit confusing).
    > I suspect that the main form of composite grouping is going to be
    > between parents and children. E.g. you might want to say things like:
    > create_group(A, memory=1G, cpu=100)
    > create_group(B, parent=A, memory=inherit, cpu=20)
    > create_group(C, parent=A, memory=inherit, cpu=30)
    > i.e. both B and C inherit/share their memory limit from their parent,
    > but have their own CPU groups (child groups of their parent?)

    No, we don't plan on doing that. What we plan on doing is

    1. Specify the mount point for each controller
    2. In the create group API, specify the name of the group and the various

    If for example CPU is mounted at /cpu and Memory at /mem

    Then a specification for creation of group A would be of the form

    create_group(A, cpu=100, memory=100M)


    /cpu/A has shares set to 100 and /mem/A has memory.limit set to 100M

    If you want to create subgroups under A, you specify

    create_group(A/B, memory=200M, cpu=50)

    That would create /cpu/A/B and /mem/A/B

    Please note that memory and CPU hierarchy needs work in the kernel. The shares
    and hierarchy support is pending. We need to make the res_counters
    infrastructure aware of hierarchies.

    Warm Regards,
    Balbir Singh
    Linux Technology Center

     \ /
      Last update: 2008-03-05 15:29    [W:0.033 / U:232.916 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site