lkml.org 
[lkml]   [2009]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] CFQ group scheduling structure organization
    On Mon, Dec 21, 2009 at 01:16:19PM +0100, Jens Axboe wrote:
    > On Thu, Dec 17 2009, Munehiro Ikeda wrote:
    > > Hello,
    > >
    > > Corrado Zoccolo wrote, on 12/17/2009 06:41 AM:
    > >> Hi,
    > >> On Wed, Dec 16, 2009 at 11:52 PM, Vivek Goyal<vgoyal@redhat.com> wrote:
    > >>> 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.
    > >>>
    > >>> [snip]
    > >>>
    > >>> 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.
    > >
    > > I agree it might be dynamic but I don't think it's un-intuitive.
    > > I think it's reasonable that disk share of a group is
    > > influenced by the number of tasks running in root group,
    > > because the root group is shared by the tasks and groups from
    > > the viewpoint of cgroup I/F, and they really share disk bandwidth.
    >
    > Agree, this is my preferred solution as well. There are definitely valid
    > cases for both doing system wide RT and system wide idle, and there are
    > definitely valid reasons for doing that inside a single group as well.
    >

    Thanks Jens. I will write a patch to implement above.

    Vivek


    \
     
     \ /
      Last update: 2009-12-21 15:45    [W:0.026 / U:30.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site