Re: Regarding dm-ioband tests

[Balbir Singh]

* Ryo Tsuruta <ryov@xxxxxxxxxxxxx> [2009-09-16 00:12:37]:

> Hi Dhaval,
> 
> Dhaval Giani <dhaval@xxxxxxxxxxxxxxxxxx> wrote:
> > > Dhaval Giani <dhaval@xxxxxxxxxxxxxxxxxx> wrote:
> > > > > I know that cgroup is a very well defined functionality, that is why
> > > > > dm-ioband also supports throttling per cgroup. But how are we supposed
> > > > > to do throttling on the system which doesn't support cgroup?
> > > > > As I wrote in another mail to Vivek, I would like to make use of
> > > > > dm-ioband on RHEL 5.x. 
> > > > 
> > > > Hi Ryo,
> > > > 
> > > > I am not sure that upstream should really be worrying about RHEL 5.x.
> > > > cgroups is a relatively mature solution and is available in most (if not
> > > > all) community distros today. We really should not be looking at another
> > > > grouping solution if the sole reason is that then dm-ioband can be used
> > > > on RHEL 5.x. The correct solution would be to maintain a separate patch
> > > > for RHEL 5.x then and not to burden the upstream kernel.
> > > 
> > > RHEL 5.x is not the sole reason for that.
> > > 
> > 
> > Could you please enumerate the other reasons for pushing in another
> > grouping mechanism then? (Why can we not resolve them via cgroups?)
> 
> I'm sorry for late reply.
> 
> I'm not only pushing in the grouping mechanism by using the dmsetup
> command. Please understand that dm-ioband also provides cgroup
> interface and can be configured in the same manner like other cgroup
> subsystems.
> Why it is so bad to have multiple ways to configure? I think that it
> rather gains in flexibility of configurations.
>

The main issue I see is user confusion and distro issues. If a distro
compiles cgroups and dmsetup provides both methods, what method
do we recommend to end users? Also should system management tool
support two configuration mechanisms for the same functionality?
 

-- 
	Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/