This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: dm-ioband + bio-cgroup benchmarks


> >>>>> 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.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>