linux-kernel - Re: dm-ioband + bio-cgroup benchmarks

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]

Message-Id: <20080926.220418.83079316.taka@valinux.co.jp>
Date:	Fri, 26 Sep 2008 22:04:18 +0900 (JST)
From:	Hirokazu Takahashi <taka@...inux.co.jp>
To:	vgoyal@...hat.com
Cc:	ryov@...inux.co.jp, linux-kernel@...r.kernel.org,
	dm-devel@...hat.com, containers@...ts.linux-foundation.org,
	virtualization@...ts.linux-foundation.org,
	xen-devel@...ts.xensource.com, fernando@....ntt.co.jp,
	balbir@...ux.vnet.ibm.com, xemul@...nvz.org, agk@...rceware.org,
	righi.andrea@...il.com, jens.axboe@...cle.com
Subject: Re: dm-ioband + bio-cgroup benchmarks

Hi,

> > > > It's possible the algorithm of dm-ioband can be placed in the block layer
> > > > if it is really a big problem.
> > > > But I doubt it can control every control block I/O as we wish since
> > > > the interface the cgroup supports is quite poor.
> > > 
> > > Had a question regarding cgroup interface. I am assuming that in a system,
> > > one will be using other controllers as well apart from IO-controller.
> > > Other controllers will be using cgroup as a grouping mechanism.
> > > Now coming up with additional grouping mechanism for only io-controller seems
> > > little odd to me. It will make the job of higher level management software
> > > harder.
> > > 
> > > Looking at the dm-ioband grouping examples given in patches, I think cases
> > > of grouping based  in pid, pgrp, uid and kvm can be handled by creating right
> > > cgroup and making sure applications are launched/moved into right cgroup by
> > > user space tools. 
> > 
> > Grouping in pid, pgrp and uid is not the point, which I've been thinking
> > can be replaced with cgroup once the implementation of bio-cgroup is done.
> > 
> > I think problems of cgroup are that they can't support lots of storages
> > and hotplug devices, it just handle them as if they were just one resource.
> > I don't insist the interface of dm-ioband is the best. I just hope the
> > cgroup infrastructure support this kind of resources.
> > 
> 
> Sorry, I did not understand fully. Can you please explain in detail what
> kind of situation will not be covered by cgroup interface.

>From the concept of the cgroup, if you want control several disks
independently, you should make each disk have its own cgroup subsystem,
which only can be defined when compiling the kernel. This is impossible
because every linux box has various number of disks.

So you think it may be possible to make each cgroup have lots of control
files for each device as a workaround. But it isn't allowed to add/remove
control files when some devices are hot-added or hot-removed.

Thanks,
Hirokazu Takahashi.
--
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/