[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090421135723.GA13953@redhat.com>
Date: Tue, 21 Apr 2009 09:57:23 -0400
From: Mike Snitzer <snitzer@...hat.com>
To: device-mapper development <dm-devel@...hat.com>
Cc: nauman@...gle.com, fernando@....ntt.co.jp,
linux-kernel@...r.kernel.org, jmoyer@...hat.com, vgoyal@...hat.com,
jens.axboe@...cle.com, agk@...hat.com, balbir@...ux.vnet.ibm.com
Subject: Re: dm-ioband: Test results.
On Tue, Apr 21 2009 at 8:10am -0400,
Ryo Tsuruta <ryov@...inux.co.jp> wrote:
> Hi Nauman,
>
> > > The real question is, once you create a version of dm-ioband that
> > > co-operates with CFQ scheduler, how that solution would compare with
> > > the patch set Vivek has posted? In my opinion, we need to converge to
> > > one solution as soon as possible, so that we can work on it together
> > > to refine and test it.
> >
> > I think I can do some help for your work. but I want to continue the
> > development of dm-ioband, because dm-ioband actually works well and
> > I think it has some advantages against other IO controllers.
> > - It can use without cgroup.
> > - It can control bandwidth on a per partition basis.
> > - The driver module can be replaced without stopping the system.
>
> In addition, dm-ioband can run on the RHEL5.
RHEL5 compatibility does not matter relative to merging an I/O bandwidth
controller upstream. So both the "can [be] use without cgroup" and "can
run on RHEL5" features do not help your cause of getting dm-ioband
merged upstream. In fact these features serve as distractions.
Mike
--
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