[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.152 / U:6.484 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site