linux-kernel - Re: Regarding dm-ioband tests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Sep 2009 16:58:49 +0900 (JST)
From:	Ryo Tsuruta <ryov@...inux.co.jp>
To:	dhaval@...ux.vnet.ibm.com
Cc:	vgoyal@...hat.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,
	balbir@...ux.vnet.ibm.com
Subject: Re: Regarding dm-ioband tests

Hi,

Dhaval Giani <dhaval@...ux.vnet.ibm.com> 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.

> > And I don't think that the grouping methods are not complicated, just
> > stack a new device on the existing device and assign bandwidth to it,
> > that is the same method as other device-mapper targets, if you would
> > like to assign bandwidth per thread, then register the thread's ID to
> > the device and assign bandwidth to it as well. I don't think it makes
> > users confused.
> > 
> > > I would tend to agree with this. With other resource management
> > > controllers using cgroups, having dm-ioband use something different will
> > > require a different set of userspace tools/libraries to be used.
> > > Something that will severly limit its usefulness froma programmer's
> > > perspective.
> > 
> > Once we create a dm-ioband device, the device can be configured
> > through the cgroup interface. I think it will not severly limit its
> > usefulness.
> > 
> 
> My objection is slightly different. My objection is that there are too
> many interfaces to do the same thing.

Not too many, There are only two interfaces device-mapper and cgroup.

> Which one of these is the recommended one? 

I think whichever users like, it's up to users.

> WHich one is going to be supported?

Both device-mapper and cgroup interfaces are supported continuously.

> If we say that cgroups is not the preferred interface, do the
> application developers need to use yet another library for io
> control along with cpu/memory control?

I don't think that cgroup is not the preferred interface, especially
not if dm-ioband uses with cpu/memory controller together. Once a
dm-ioband device is created, all configurations for the device can be
done through the cgroup interface like other cgroup subsystems. It
does not require a different set of userspace tools/libraries to be
used.

I think it is natural to make dm-ioband can be configured by
device-mapper's interface since dm-ioband is a device-mapper driver,
and it extends use case, rather it limits usefulness.

Thanks,
Ryo Tsuruta
--
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/