From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id 088015F0048 for ; Wed, 20 Oct 2010 00:12:23 -0400 (EDT) Received: from m4.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o9K4CL5u017225 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Wed, 20 Oct 2010 13:12:21 +0900 Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 2F50C45DE6E for ; Wed, 20 Oct 2010 13:12:21 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 1291A45DE60 for ; Wed, 20 Oct 2010 13:12:21 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id F13131DB803A for ; Wed, 20 Oct 2010 13:12:20 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id AABD2EF8001 for ; Wed, 20 Oct 2010 13:12:20 +0900 (JST) Date: Wed, 20 Oct 2010 13:06:54 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [PATCH v3 02/11] memcg: document cgroup dirty memory interfaces Message-Id: <20101020130654.bf861eda.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <1287448784-25684-1-git-send-email-gthelen@google.com> <1287448784-25684-3-git-send-email-gthelen@google.com> <20101019172744.45e0a8dc.nishimura@mxp.nes.nec.co.jp> <20101020091109.ccd7b39a.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Greg Thelen Cc: Daisuke Nishimura , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, containers@lists.osdl.org, Andrea Righi , Balbir Singh , Minchan Kim , Ciju Rajan K , David Rientjes List-ID: On Tue, 19 Oct 2010 17:45:08 -0700 Greg Thelen wrote: > KAMEZAWA Hiroyuki writes: > > BTW, how about supporing dirty_limit_in_bytes when use_hierarchy=0 or > > leave it as broken when use_hierarchy=1 ? It seems we can only > > support dirty_ratio when hierarchy is used. > > I am not sure what you mean here. When using dirty_ratio, we can check the value of dirty_ratio at setting it and make guarantee that any children's dirty_ratio cannot exceeds it parent's. If we guarantee that, we can keep dirty_ratio even under hierarchy. When it comes to dirty_limit_in_bytes, we never able to do such kind of controls. So, it will be broken and will do different behavior than dirty_ratio. So, not supporing dirty_bytes when use_hierarchy==1 for now sounds reasonable to me. Thanks, -Kame -- 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