Hi, > >>>>> It's possible the algorithm of dm-ioband can be placed in the block layer > >>>>> if it is really a big problem. > >>>>> But I doubt it can control every control block I/O as we wish since > >>>>> the interface the cgroup supports is quite poor. > >>>> Had a question regarding cgroup interface. I am assuming that in a system, > >>>> one will be using other controllers as well apart from IO-controller. > >>>> Other controllers will be using cgroup as a grouping mechanism. > >>>> Now coming up with additional grouping mechanism for only io-controller seems > >>>> little odd to me. It will make the job of higher level management software > >>>> harder. > >>>> > >>>> Looking at the dm-ioband grouping examples given in patches, I think cases > >>>> of grouping based in pid, pgrp, uid and kvm can be handled by creating right > >>>> cgroup and making sure applications are launched/moved into right cgroup by > >>>> user space tools. > >>> Grouping in pid, pgrp and uid is not the point, which I've been thinking > >>> can be replaced with cgroup once the implementation of bio-cgroup is done. > >>> > >>> I think problems of cgroup are that they can't support lots of storages > >>> and hotplug devices, it just handle them as if they were just one resource. > >>> I don't insist the interface of dm-ioband is the best. I just hope the > >>> cgroup infrastructure support this kind of resources. > >>> > >> Sorry, I did not understand fully. Can you please explain in detail what > >> kind of situation will not be covered by cgroup interface. > > > > From the concept of the cgroup, if you want control several disks > > independently, you should make each disk have its own cgroup subsystem, > > which only can be defined when compiling the kernel. This is impossible > > because every linux box has various number of disks. > > mmh? not true. You can define a single cgroup subsystem that implements > the opportune interfaces to apply your type of control, and use many > structures allocated dynamically for each controlled object (one for > each block device, disk, partition, ... or using any kind of > grouping/splitting policy). Actually, this is how cgroup-io-throttle, as > well as any other cgroup subsystem, is implemented. > > > So you think it may be possible to make each cgroup have lots of control > > files for each device as a workaround. But it isn't allowed to add/remove > > control files when some devices are hot-added or hot-removed. > > Why not a single control file for all the devices? This is possible but I wonder if this is really the way we should go. It looks like you tried implementing another ioctl-like interface on the cgroup control file interface. You can do anything you want with this interface though. I guess there should be at least some rules to implement this kind of ioctl-like interface if they don't want to enhance the cgroup interface, Thank you, Hirokazu Takahashi. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
