[lkml]   [2009]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] CFQ group scheduling structure organization
    On Thu, Dec 17, 2009 at 06:58:21PM -0500, 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<> 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.

    That's true that it becomes more natural to view it that way. That's a
    different thing that it might become little more work in user space to
    then move root tasks into a sub group otherwise, the effective share of
    a newly created group might be really less. All the tasks in a group are
    effectively a single task when it comes to top level.

    >>> 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.
    >> This is the one I prefer: it is the most natural one if you see that
    >> groups are scheduling entities like any other task.
    >> I think it becomes intuitive with an analogy with a qemu (e.g. kvm)
    >> virtual machine model. If you think a group like a virtual machine, it
    >> is clear that for the normal system, the whole virtual machine is a
    >> single scheduling entity, and that it has to compete with other
    >> virtual machines (as other single entities) and every process in the
    >> real system (those are inherently more important, since without the
    >> real system, the VMs cannot simply exist).
    >> Having a designated root group, instead, resembles the xen VM model,
    >> where you have a separated domain for each VM and for the real system.
    >> I think the implementation of this approach can make the code simpler
    >> and modular (CFQ could be abstracted to deal with scheduling entities,
    >> and each scheduling entity could be defined in a separate file).
    >> Within each group, you will now have the choice of how to schedule its
    >> queues. This means that you could possibly have different I/O
    >> schedulers within each group, and even have sub-groups within groups.
    > Corrado exactly says my preference.
    > I understand current implementation, like proposal 1, was
    > employed to make code simple and I believe it succeeded.
    > However, rather I feel it's un-intuitive because it's
    > inconsistent with cgroup I/F. Behavior which is inconsistent
    > with the I/F can lead to misconfiguration of sys-admins.
    > This might be problematic, IMHO.

    Thanks Muuhh. It helps to get perspective from various folks before I
    start implementing it.


     \ /
      Last update: 2009-12-18 17:07    [W:0.031 / U:0.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site