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: <48DD0617.3050403@gmail.com>
Date:	Fri, 26 Sep 2008 17:56:07 +0200
From:	Andrea Righi <righi.andrea@...il.com>
To:	Hirokazu Takahashi <taka@...inux.co.jp>
CC:	vgoyal@...hat.com, 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,
	jens.axboe@...cle.com
Subject: Re: dm-ioband + bio-cgroup benchmarks

Hirokazu Takahashi wrote:
> 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.

mmh? not true. You can define a single cgroup subsystem that implements
the opportune interfaces to apply your type of control, and use many
structures allocated dynamically for each controlled object (one for
each block device, disk, partition, ... or using any kind of
grouping/splitting policy). Actually, this is how cgroup-io-throttle, as
well as any other cgroup subsystem, is implemented.

> 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.

Why not a single control file for all the devices?

-Andrea
--
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/