Re: [RFC] CFQ group scheduling structure organization

[Vivek Goyal <vgoyal@redhat.com>]

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