linux-kernel - Re: [PATCH 0/9] cgroup: io-throttle controller (v13)

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, 16 Apr 2009 15:24:33 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andrea Righi <righi.andrea@...il.com>
Cc:	menage@...gle.com, balbir@...ux.vnet.ibm.com,
	guijianfeng@...fujitsu.com, kamezawa.hiroyu@...fujitsu.com,
	agk@...rceware.org, axboe@...nel.dk, baramsori72@...il.com,
	chlunde@...g.uio.no, dave@...ux.vnet.ibm.com, dpshah@...gle.com,
	eric.rannaud@...il.com, fernando@....ntt.co.jp, taka@...inux.co.jp,
	lizf@...fujitsu.com, matt@...ehost.com, dradford@...ehost.com,
	ngupta@...gle.com, randy.dunlap@...cle.com, roberto@...it.it,
	ryov@...inux.co.jp, s-uchida@...jp.nec.com,
	subrata@...ux.vnet.ibm.com, yoshikawa.takuya@....ntt.co.jp,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] cgroup: io-throttle controller (v13)

On Tue, 14 Apr 2009 22:21:11 +0200
Andrea Righi <righi.andrea@...il.com> wrote:

> Objective
> ~~~~~~~~~
> The objective of the io-throttle controller is to improve IO performance
> predictability of different cgroups that share the same block devices.

We should get an IO controller into Linux.  Does anyone have a reason
why it shouldn't be this one?

> Respect to other priority/weight-based solutions the approach used by
> this controller is to explicitly choke applications' requests

Yes, blocking the offending application at a high level has always
seemed to me to be the best way of implementing the controller.

> that
> directly or indirectly generate IO activity in the system (this
> controller addresses both synchronous IO and writeback/buffered IO).

The problem I've seen with some of the proposed controllers was that
they didn't handle delayed writeback very well, if at all.

Can you explain at a high level but in some detail how this works?  If
an application is doing a huge write(), how is that detected and how is
the application made to throttle?

Does it add new metadata to `struct page' for this?

I assume that the write throttling is also wired up into the MAP_SHARED
write-fault path?

Does this patchset provide a path by which we can implement IO control
for (say) NFS mounts?

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