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: <20080917.161811.27257227.taka@valinux.co.jp>
Date:	Wed, 17 Sep 2008 16:18:11 +0900 (JST)
From:	Hirokazu Takahashi <taka@...inux.co.jp>
To:	righi.andrea@...il.com
Cc:	balbir@...ux.vnet.ibm.com, menage@...gle.com, agk@...rceware.org,
	akpm@...ux-foundation.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,
	lizf@...fujitsu.com, m.innocenti@...eca.it, matt@...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: [RFC][PATCH -mm 0/5] cgroup: block device i/o controller (v9)

Hi,

> TODO:
> 
> * Try to push down the throttling and implement it directly in the I/O
>   schedulers, using bio-cgroup (http://people.valinux.co.jp/~ryov/bio-cgroup/)
>   to keep track of the right cgroup context. This approach could lead to more
>   memory consumption and increases the number of dirty pages (hard/slow to
>   reclaim pages) in the system, since dirty-page ratio in memory is not
>   limited. This could even lead to potential OOM conditions, but these problems
>   can be resolved directly into the memory cgroup subsystem
> 
> * Handle I/O generated by kswapd: at the moment there's no control on the I/O
>   generated by kswapd; try to use the page_cgroup functionality of the memory
>   cgroup controller to track this kind of I/O and charge the right cgroup when
>   pages are swapped in/out

FYI, this also can be done with bio-cgroup, which determine the owner cgroup
of a given anonymous page.

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/