lkml.org 
[lkml]   [2009]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[RFC] CFQ group scheduling structure organization
    Date
    Hi All,

    With some basic group scheduling support in CFQ, there are few questions
    regarding how group structure should look like in CFQ.

    Currently, grouping looks as follows. A, and B are two cgroups created by
    user.

    Proposal 1:
    =========
    grp-service-tree
    / | \
    root A B

    One issue with this structure is that RT tasks are not system wide. So an
    RT tasks inside root group has RT priority only with-in root group. So a
    BE task inside A will get it fair share despite the fact that root has got
    RT tasks.


    Proposal 2:
    ==========
    One proposal to solve this issue is that make RT and IDLE tasks system
    wide and provide weight based service differentiation only for BE class
    tasks. So RT or IDLE tasks running in any of the groups will automatically
    move to one global RT group maintained by CFQ internally. Same is true for
    IDLE tasks. But BE class tasks will honor the cgroup limitations and will
    get differentiated service according to weight.

    Internal structure will look as follows.

    grp-RT-service-tree grp-BE-service-tree grp-IDLE-service-tree
    | / \ |
    all_RT_task_group A B all_idle_tasks_grp


    Here A and B are two cgroups and some BE tasks might be running inside
    those groups. systemwide RT tasks will move under all_RT_task_group and
    all idle tasks will move under all_idle_tasks_grp.

    So one will notice service differentiation only for BE tasks.


    Proposal 3:
    ===========

    One can argue that we need group service differentiation for RT class
    tasks also and don't move tasks automatically across groups. That means
    we need to support "group class" type also. Probably we can support
    three classes of cgroups RT, BE and IDLE and CFQ will use that data to
    put cgroups in respective tree.

    Things should look as follows.

    grp-RT-service-tree grp-BE-service-tree grp-IDLE-service-tree
    / \ / \ / \
    C D A B E F


    Here A and B are BE type groups created by user.
    C and D are RT type cgroups created by user.
    E and F are IDLE type cgroups created by user.

    Now in this scheme of things, by default root will be of type BE. Any task
    RT task under "root" group will not be system wide RT task. It will be RT
    only with-in root group. To make it system wide idle, admin shall have to
    create a new cgroup, say C, of type RT and move task in that cgroup.
    Because RT group C is system wide, now that task becomes system wide RT.

    So this scheme might throw some surprise to existing users. They might
    create a new group and not realize that their RT tasks are no more system
    wide RT tasks and they need to specifically create one RT cgroup and move
    all RT tasks in that cgroup.

    Practically I am not sure how many people are looking for group service
    differentiation for RT and IDLE class tasks also.

    Proposal 4:
    ==========
    Treat task and group at same level. Currently groups are at top level and
    at second level are tasks. View the whole hierarchy as follows.


    service-tree
    / | \ \
    T1 T2 G1 G2

    Here T1 and T2 are two tasks in root group and G1 and G2 are two cgroups
    created under root.

    In this kind of scheme, any RT task in root group will still be system
    wide RT even if we create groups G1 and G2.

    So what are the issues?

    - I talked to few folks and everybody found this scheme not so intutive.
    Their argument was that once I create a cgroup, say A, under root, then
    bandwidth should be divided between "root" and "A" proportionate to
    the weight.

    It is not very intutive that group is competing with all the tasks
    running in root group. And disk share of newly created group will change
    if more tasks fork in root group. So it is highly dynamic and not
    static hence un-intutive.

    To emulate the behavior of previous proposals, root shall have to create
    a new group and move all root tasks there. But admin shall have to still
    keep RT tasks in root group so that they still remain system-wide.

    service-tree
    / | \ \
    T1 root G1 G2
    |
    T2

    Now admin has specifically created a group "root" along side G1 and G2
    and moved T2 under root. T1 is still left in top level group as it might
    be an RT task and we want it to remain RT task systemwide.

    So to some people this scheme is un-intutive and requires more work in
    user space to achive desired behavior. I am kind of 50:50 between two
    kind of arrangements.


    I am looking for some feedback on what makes most sense.

    For the time being, I am little inclined towards proposal 2 and I have
    implemented a proof of concept version on top of for-2.6.33 branch in block
    tree. These patches are compile and boot tested only and I have yet to do
    testing.

    Thanks
    Vivek



    \
     
     \ /
      Last update: 2009-12-16 23:59    [W:3.289 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site