linux-kernel - Re: [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9)

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: <48C16E92.5000402@gmail.com>
Date:	Fri, 05 Sep 2008 19:38:26 +0200
From:	Andrea Righi <righi.andrea@...il.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Paul Menage <menage@...gle.com>, randy.dunlap@...cle.com,
	Carl Henrik Lunde <chlunde@...g.uio.no>,
	Divyesh Shah <dpshah@...gle.com>, eric.rannaud@...il.com,
	fernando@....ntt.co.jp, akpm@...ux-foundation.org,
	agk@...rceware.org, subrata@...ux.vnet.ibm.com, axboe@...nel.dk,
	Marco Innocenti <m.innocenti@...eca.it>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, dave@...ux.vnet.ibm.com,
	matt@...ehost.com, roberto@...it.it, ngupta@...gle.com,
	dradford@...ehost.com, ryov@...inux.co.jp
Subject: Re: [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9)

Vivek Goyal wrote:
> Ok, to be more specific, I was thinking of following.
> 
> Currently, all the requests for a block device go into request queue in
> a linked list and then associated elevator selects the best request for
> dispatch based on various policies as dictated by elevator.
> 
> Can we maintan an rb-tree per request queue and all the requests being
> queued on that request queue first will go in this rb-tree. Then based on
> cgroup grouping and control policy (max bandwidth capping, proportional
> bandwidth etc), one can pass the requests to elevator associated with the
> queue (which will do the actual job of merging and other things).

Could a workqueue like kblockd move requests from rb-tree to the equivalent
request queue?

> 
> So effectively first we provide control at cgroup level and then let
> elevator take the best decisions with in that.

I think I've to figure better all the implementation details, but yes,
sounds good. This seems to be the right approach to provide any kind of
IO controlling: bandwidth throttling, proportional bandwidth,
ionice-like approach, etc.

> This should not require creation of any dm-ioband devices to control the
> devices. Each block device will contain one rb-tree (cgroups hanging) as
> long has somebody has put a controlling policy on that devices. (We can
> probably use your interfaces to create policies on devices through cgroup
> files).
> 
> This should not require elevator modifications and should work well with
> stacked devices. 
> 
> I will try to write some prototype patches and see if all the above
> gibber makes any sense and is workable or not.

That would be great!

> 
> One limitation in this scheme is that we are providing grouping capability
> based on cgroups only and it is not as generic what dm-ioband is providing.
> Do we really require other ways of creating grouping. Creating another device
> for each device you want to control sounds odd to me.

In any case libcgroup could help here to define any grouping policy
(uid, gid, pid, ...). So, IMHO the grouping capability provided by
cgroups is in perspective generic as well as what dm-ioband provides.

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