[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090908134915.GB15974@redhat.com>
Date: Tue, 8 Sep 2009 09:49:15 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Ryo Tsuruta <ryov@...inux.co.jp>
Cc: balbir@...ux.vnet.ibm.com, riel@...hat.com,
linux-kernel@...r.kernel.org, dm-devel@...hat.com,
jens.axboe@...cle.com, agk@...hat.com, akpm@...ux-foundation.org,
nauman@...gle.com, guijianfeng@...fujitsu.com, jmoyer@...hat.com
Subject: Re: Regarding dm-ioband tests
On Tue, Sep 08, 2009 at 02:05:16PM +0900, Ryo Tsuruta wrote:
> Hi Balbir,
>
> Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> > * Ryo Tsuruta <ryov@...inux.co.jp> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists