From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <47CFA941.4070507@openvz.org> Date: Thu, 06 Mar 2008 11:20:17 +0300 From: Pavel Emelyanov MIME-Version: 1.0 Subject: Re: [RFC/PATCH] cgroup swap subsystem References: <47CE36A9.3060204@mxp.nes.nec.co.jp> <47CE5AE2.2050303@openvz.org> <47CEAAB4.8070208@openvz.org> <20080306093324.77c6d7f4.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20080306093324.77c6d7f4.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: KAMEZAWA Hiroyuki Cc: Hugh Dickins , Daisuke Nishimura , containers@lists.osdl.org, linux-mm@kvack.org, balbir@linux.vnet.ibm.com List-ID: KAMEZAWA Hiroyuki wrote: > On Wed, 05 Mar 2008 17:14:12 +0300 > Pavel Emelyanov wrote: >>> Strongly agree. Nobody's interested in swap as such: it's just >>> secondary memory, where RAM is primary memory. People want to >>> control memory as the sum of the two; and I expect they may also >>> want to control primary memory (all that the current memcg does) >>> within that. I wonder if such nesting of limits fits easily >>> into cgroups or will be problematic. >> This nesting would affect the res_couter abstraction, not the >> cgroup infrastructure. Current design of resource counters doesn't >> allow for such thing, but the extension is a couple-of-lines patch :) >> > IMHO, keeping res_counter simple is better. > > Is this kind of new entry in mem_cgroup not good ? > == > struct mem_cgroup { > ... > struct res_counter memory_limit. > struct res_counter swap_limit. > .. > } I meant the same thing actually. By "nesting would affect" I meant, that we might want to make res_counters hierarchical. That would kill two birds with one stone - we will make a true hierarchical memory accounting and let charging of two counters with one call. > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org