Hi Vivek, Vivek Goyal <vgoyal@xxxxxxxxxx> 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. O.K. > > - 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. Thanks, Ryo Tsuruta -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
