From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by e28esmtp06.in.ibm.com (8.13.1/8.13.1) with ESMTP id m714DiiG013501 for ; Fri, 1 Aug 2008 09:43:44 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m714DhFO811186 for ; Fri, 1 Aug 2008 09:43:44 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.13.1/8.13.3) with ESMTP id m714Dg2O005244 for ; Fri, 1 Aug 2008 09:43:43 +0530 Message-ID: <48928D77.3090306@linux.vnet.ibm.com> Date: Fri, 01 Aug 2008 09:43:43 +0530 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com MIME-Version: 1.0 Subject: Re: memo: mem+swap controller References: <20080731101533.c82357b7.kamezawa.hiroyu@jp.fujitsu.com> <20080731152533.dea7713a.nishimura@mxp.nes.nec.co.jp> <489282C7.2020500@linux.vnet.ibm.com> <20080801130203.b220f3a1.nishimura@mxp.nes.nec.co.jp> In-Reply-To: <20080801130203.b220f3a1.nishimura@mxp.nes.nec.co.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Daisuke Nishimura Cc: KAMEZAWA Hiroyuki , "hugh@veritas.com" , "linux-mm@kvack.org" , "menage@google.com" , Andrew Morton List-ID: Daisuke Nishimura wrote: > On Fri, 01 Aug 2008 08:58:07 +0530, Balbir Singh wrote: >> Daisuke Nishimura wrote: >>> Hi, Kamezawa-san. >>> >>> On Thu, 31 Jul 2008 10:15:33 +0900, KAMEZAWA Hiroyuki wrote: >>>> Hi, mem+swap controller is suggested by Hugh Dickins and I think it's a great >>>> idea. Its concept is having 2 limits. (please point out if I misunderstand.) >>>> >>>> - memory.limit_in_bytes .... limit memory usage. >>>> - memory.total_limit_in_bytes .... limit memory+swap usage. >>>> >>> When I've considered more, I wonder how we can accomplish >>> "do not use swap in this group". >>> >> It's easy use the memrlimit controller and set virtual address limit <= >> memory.limit_in_bytes. I use that to make sure I never swap out. >> > I don't think it works under memory pressure *outside* of the group, > that is, global memory reclaim. > (I think "limit_in_bytes == total_limit_in_bytes" also works *inside* memory > pressure.) > Yes, but it ensures that the current cgroup does not add to global swap pressure. Trying to control global pressure from inside a cgroup might be hard, but I see your intention of isolating the cgroup from global pressure. With swappiness, it should be possible to purge page cache ahead of creating swap pressure. >>> Setting "limit_in_bytes == total_limit_in_bytes" doesn't meet it, I think. >>> "limit_in_bytes = total_limit_in_bytes = 1G" cannot >>> avoid "memory.usage = 700M swap.usage = 300M" under memory pressure >>> outside of the group(and I think this behavior is the diffrence >>> of "memory controller + swap controller" and "mem+swap controller"). >>> >>> I think total_limit_in_bytes and swappiness(or some flag to indicate >>> "do not swap out"?) for each group would make more sense. >> I do intend to add the swappiness feature soon for control groups. >> > How does it work? > Does it affect global page reclaim? > We have a swappiness parameter in scan_control. Each control group indicates what it wants it swappiness to be when the control group is over it's limit and reclaim kicks in. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- 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