[lkml]   [2009]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Regarding dm-ioband tests
    On Wed, Sep 09, 2009 at 02:17:48PM +0900, Ryo Tsuruta wrote:
    > Hi Vivek,
    > Vivek Goyal <> wrote:
    > > > It is not necessary when controlling bandwidth on a per partition
    > > > basis or on a IO thread basis like Xen blkback kernel thread.
    > > >
    > > > Here are configration examples.
    > > >
    > > >
    > >
    > > For partition based control, where a thread or group of threads is doing
    > > IO to a specific parition, why can't you simply create different cgroups
    > > for each partition and move threads in those partitions.
    > >
    > >
    > > root
    > > / | \
    > > sda1 sda2 sda3
    > >
    > > Above are three groups and move threads doing IO into those groups and
    > > problem is solved. In fact that's what one will do for KVM virtual
    > > machines. Move all the qemu helper threds doing IO for a virtual machine
    > > instance into a specific group and control the IO.
    > >
    > > Why do you have to come up with additional complicated grouping mechanism?
    > I don't get why you think it's complicated, your io-controller also
    > provides the same grouping machanism which assigns bandwidth per
    > device by io.policy file. What's the difference?

    I am using purely cgroup based interface. This makes life easier for user
    space tools and libraries like libcgroup and should also help libvirt. Now
    they can treat all the resource controllers in kernel in a uniform way
    (through cgroup interface).

    With-in cgroups, there are controller specific files and libcgroup is
    aware of that. So libcgroup can be modified to take care of special
    syntax of io.policy file. But this is not too big a deviation in overall

    dm-ioband is coming up with a whole new way of configuring and managing
    groups and now these user space tools shall have to be modified to take
    care of this new way only for io controller.

    The point is there is no need. You seem to be introducing this new
    interface because you want to use this module with RHEL5 which does not
    have cgroup support.

    I think this is hard to sell argument that upstream should also introduce
    a new interface just because one wants to use the module with older
    releases of kernel which did not have cgroup support.

    Taking this new interface solves your case but will make life harder for user
    space tools, libraries and applications making use of cgroups and various
    resource controllers.

    > The thread grouping
    > machianism is also not special, it is the same concept as cgroup.
    > These mechanisms are necessary to make use of dm-ioband on the systems
    > which doesn't support cgroup such as RHEL 5.x. As you know, dm-ioband
    > also supports cgroup, the configurations you mentioned above can apply
    > to the system by dm-ioband.

    dm-ioband also supports cgroup but there is additional step required and
    that is passing all the cgroup ids to various ioband devices. This
    requires knowledge of all the ioband devices and how these have been
    created and usage of dm tools.

    The only place where it helps a bit is that once the configuration is
    done, one can move the tasks in groups to arbitrarily group them instead
    of grouping these on pid, gid etc....

    So it still does not solve the issue of dm-ioband being so different from
    rest of the controllers and introducing a new interface for creation and
    management of groups.

    > I think it's not bad to have several ways
    > to setup.

    It is not bad if there is a proper justification for new interface and why
    existing standard mechanism does not meet that requirement.

    In this case you are saying that in general cgroup mechanism is sufficient
    to take care of grouping of tasks but it is not available in older kernels
    hence let us introduce a new interface in upstream kernels. I think this does
    not work. This brings in unnecessary overhead of maintaining anohter interface
    for upstream and upstream does not benefit from this interface.


     \ /
      Last update: 2009-09-09 15:37    [W:0.024 / U:0.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site