[lkml]   [2009]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Regarding dm-ioband tests
    Hi Vivek,

    Vivek Goyal <> wrote:
    > > I think there are some advantages to dm-ioband. That's why I post
    > > dm-ioband to the mailing list.
    > >
    > > - dm-ioband supports not only proportional weight policy but also rate
    > > limiting policy. Besides, new policies can be added to dm-ioband if
    > > a user wants to control bandwidth by his or her own policy.
    > I think we can easily extent io scheduler based controller to also support
    > max rate per group policy also. That should not be too hard. It is a
    > matter of only keeping track of io rate per group and if a group is
    > exceeding the rate, then schedule it out and move on to next group.
    > I can do that once proportional weight solution is stablized and gets
    > merged.
    > So its not an advantage of dm-ioband.


    > > - The dm-ioband driver can be replaced without stopping the system by
    > > using device-mapper's facility. It's easy to maintain.
    > We talked about this point in the past also. In io scheduler based
    > controller, just move all the tasks to root group and you got a system
    > not doing any io control.
    > By the way why would one like to do that?
    > So this is also not an advantage.

    My point is that dm-ioband can be updated for improvements and
    bug-fixing without stopping the system.

    > > - dm-ioband can use without cgroup. (I remember Vivek said it's not an
    > > advantage.)
    > I think this is more of a disadvantage than advantage. We have a very well
    > defined functionality of cgroup in kernel to group the tasks. Now you are
    > coming up with your own method of grouping the tasks which will make life
    > even more confusing for users and application writers.
    > I don't understand what is that core requirement of yours which is not met
    > by io scheduler based io controller. range policy control you have
    > implemented recently. I don't think that removing dm-ioband module
    > dynamically is core requirement. Also whatever you can do with additional
    > grouping mechanism, you can do with cgroup also.
    > So if there is any of your core functionality which is not fulfilled by
    > io scheduler based controller, please let me know. I will be happy to look
    > into it and try to provide that feature. But looking at above list, I am
    > not convinced that any of the above is a compelling argument for dm-ioband
    > inclusion.

    As I wrote in another email, I would like to make use of dm-ioband on
    the system which doesn't support cgroup such as RHEL. In addition,
    there are devices which doesn't use standard IO schedulers, and
    dm-ioband can work on even such devices.

    Ryo Tsuruta

     \ /
      Last update: 2009-09-09 12:05    [W:0.022 / U:13.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site