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:	Wed, 09 Sep 2009 14:17:48 +0900 (JST)
From:	Ryo Tsuruta <ryov@...inux.co.jp>
To:	vgoyal@...hat.com
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

Hi Vivek,

Vivek Goyal <vgoyal@...hat.com> wrote:
> > 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?

I don't get why you think it's complicated, your io-controller also
provides the same grouping machanism which assigns bandwidth per
device by io.policy file. What's the difference? The thread grouping
machianism is also not special, it is the same concept as cgroup.
These mechanisms are necessary to make use of dm-ioband on the systems
which doesn't support cgroup such as RHEL 5.x. As you know, dm-ioband
also supports cgroup, the configurations you mentioned above can apply
to the system by dm-ioband. I think it's not bad to have several ways
to setup.

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/