On Tue, Sep 08, 2009 at 02:05:16PM +0900, Ryo Tsuruta wrote: > Hi Balbir, > > Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: > > * Ryo Tsuruta <ryov@xxxxxxxxxxxxx> [2009-09-08 12:01:19]: > > > > > 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. > > > - The dm-ioband driver can be replaced without stopping the system by > > > using device-mapper's facility. It's easy to maintain. > > > - dm-ioband can use without cgroup. (I remember Vivek said it's not an > > > advantage.) > > > > But don't you need page_cgroup for IO tracking? > > 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. > http://sourceforge.net/apps/trac/ioband/wiki/dm-ioband/man/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? Thanks Vivek -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
