KAMEZAWA Hiroyuki wrote: > On Fri, 17 Apr 2009 15:34:53 +0800 > Gui Jianfeng <guijianfeng@xxxxxxxxxxxxxx> wrote: > >> KAMEZAWA Hiroyuki wrote: >>> On Tue, 14 Apr 2009 22:21:12 +0200 >>> Andrea Righi <righi.andrea@xxxxxxxxx> wrote: >>> >>>> +Example: >>>> +* Create an association between an io-throttle group and a bio-cgroup group >>>> + with "bio" and "blockio" subsystems mounted in different mount points: >>>> + # mount -t cgroup -o bio bio-cgroup /mnt/bio-cgroup/ >>>> + # cd /mnt/bio-cgroup/ >>>> + # mkdir bio-grp >>>> + # cat bio-grp/bio.id >>>> + 1 >>>> + # mount -t cgroup -o blockio blockio /mnt/io-throttle >>>> + # cd /mnt/io-throttle >>>> + # mkdir foo >>>> + # echo 1 > foo/blockio.bio_id >>> Why do we need multiple cgroups at once to track I/O ? >>> Seems complicated to me. >> Hi Kamezawa-san, >> >> The original thought to implement this function is for sharing a bio-cgroup >> with other subsystems, such as dm-ioband. If the bio-cgroup is already mounted, >> and used by dm-ioband or others, we just need to create a association between >> io-throttle and bio-cgroup by echo a bio-cgroup id, just like what dm-ioband does. >> > > - Why we need multiple I/O controller ? > - Why bio-cgroup cannot be a _pure_ infrastructe as page_cgroup ? > - Why we need extra mount ? > > I have no answer but, IMHO, > - only one I/O controller should be enabled at once. > - bio cgroup should be tightly coupled with I/O controller and should work as > infrastructure i.e. naming/tagging I/O should be automatically done by > I/O controller. not by the user's hand. It seems dm-ioband has to make use of bio-cgroup by the user's hand. Because dm-ioband is not cgroup based. :( Is that possible that another subsystem(not cgroup based, and not an IO Controller) also would like to use bio-cgroup in the future? There's no such case at least now, so i don't object to get rid of this part. :) > > Thanks, > -Kame > > > > > -- Regards Gui Jianfeng _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
