From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta7.messagelabs.com (mail6.bemta7.messagelabs.com [216.82.255.55]) by kanga.kvack.org (Postfix) with ESMTP id 996346B004D for ; Mon, 28 Nov 2011 18:56:39 -0500 (EST) Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 533A33EE0AE for ; Tue, 29 Nov 2011 08:56:36 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 35F6445DE58 for ; Tue, 29 Nov 2011 08:56:36 +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 1C94545DE54 for ; Tue, 29 Nov 2011 08:56:36 +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 0ADDFE08001 for ; Tue, 29 Nov 2011 08:56:36 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.240.81.145]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id BC5861DB802F for ; Tue, 29 Nov 2011 08:56:35 +0900 (JST) Date: Tue, 29 Nov 2011 08:55:18 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [PATCH v6 01/10] Basic kernel memory functionality for the Memory Controller Message-Id: <20111129085518.65befeee.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <4ED36A6D.60900@parallels.com> References: <1322242696-27682-1-git-send-email-glommer@parallels.com> <1322242696-27682-2-git-send-email-glommer@parallels.com> <20111128112441.44a6e166.kamezawa.hiroyu@jp.fujitsu.com> <4ED36A6D.60900@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Glauber Costa Cc: linux-kernel@vger.kernel.org, lizf@cn.fujitsu.com, ebiederm@xmission.com, davem@davemloft.net, paul@paulmenage.org, gthelen@google.com, netdev@vger.kernel.org, linux-mm@kvack.org, kirill@shutemov.name, avagin@parallels.com, devel@openvz.org, eric.dumazet@gmail.com, cgroups@vger.kernel.org On Mon, 28 Nov 2011 09:03:09 -0200 Glauber Costa wrote: > On 11/28/2011 12:24 AM, KAMEZAWA Hiroyuki wrote: > > On Fri, 25 Nov 2011 15:38:07 -0200 > > Glauber Costa wrote: > > > >> This patch lays down the foundation for the kernel memory component > >> of the Memory Controller. > >> > >> As of today, I am only laying down the following files: > >> > >> * memory.independent_kmem_limit > >> * memory.kmem.limit_in_bytes (currently ignored) > >> * memory.kmem.usage_in_bytes (always zero) > >> > >> Signed-off-by: Glauber Costa > >> Reviewed-by: Kirill A. Shutemov > >> CC: Paul Menage > >> CC: Greg Thelen > >> --- > >> Documentation/cgroups/memory.txt | 36 ++++++++++++- > >> init/Kconfig | 14 +++++ > >> mm/memcontrol.c | 107 ++++++++++++++++++++++++++++++++++++-- > >> 3 files changed, 150 insertions(+), 7 deletions(-) > >> > >> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt > >> index 06eb6d9..bf00cd2 100644 > >> --- a/Documentation/cgroups/memory.txt > >> +++ b/Documentation/cgroups/memory.txt > >> @@ -44,8 +44,9 @@ Features: > >> - oom-killer disable knob and oom-notifier > >> - Root cgroup has no limit controls. > >> > >> - Kernel memory and Hugepages are not under control yet. We just manage > >> - pages on LRU. To add more controls, we have to take care of performance. > >> + Hugepages is not under control yet. We just manage pages on LRU. To add more > >> + controls, we have to take care of performance. Kernel memory support is work > >> + in progress, and the current version provides basically functionality. > >> > >> Brief summary of control files. > >> > >> @@ -56,8 +57,11 @@ Brief summary of control files. > >> (See 5.5 for details) > >> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap > >> (See 5.5 for details) > >> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only. > >> + (See 2.7 for details) > >> memory.limit_in_bytes # set/show limit of memory usage > >> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage > >> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory > >> memory.failcnt # show the number of memory usage hits limits > >> memory.memsw.failcnt # show the number of memory+Swap hits limits > >> memory.max_usage_in_bytes # show max memory usage recorded > >> @@ -72,6 +76,9 @@ Brief summary of control files. > >> memory.oom_control # set/show oom controls. > >> memory.numa_stat # show the number of memory usage per numa node > >> > >> + memory.independent_kmem_limit # select whether or not kernel memory limits are > >> + independent of user limits > >> + > >> 1. History > >> > >> The memory controller has a long history. A request for comments for the memory > >> @@ -255,6 +262,31 @@ When oom event notifier is registered, event will be delivered. > >> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by > >> zone->lru_lock, it has no lock of its own. > >> > >> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM) > >> + > >> + With the Kernel memory extension, the Memory Controller is able to limit > >> +the amount of kernel memory used by the system. Kernel memory is fundamentally > >> +different than user memory, since it can't be swapped out, which makes it > >> +possible to DoS the system by consuming too much of this precious resource. > >> +Kernel memory limits are not imposed for the root cgroup. > >> + > >> +Memory limits as specified by the standard Memory Controller may or may not > >> +take kernel memory into consideration. This is achieved through the file > >> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel > >> +memory to be controlled separately. > >> + > >> +When kernel memory limits are not independent, the limit values set in > >> +memory.kmem files are ignored. > >> + > >> +Currently no soft limit is implemented for kernel memory. It is future work > >> +to trigger slab reclaim when those limits are reached. > >> + > >> +CAUTION: As of this writing, the kmem extention may prevent tasks from moving > >> +among cgroups. If a task has kmem accounting in a cgroup, the task cannot be > >> +moved until the kmem resource is released. Also, until the resource is fully > >> +released, the cgroup cannot be destroyed. So, please consider your use cases > >> +and set kmem extention config option carefully. > >> + > > > > This seems that memcg 'has' kernel memory limiting feature for all kinds of kmem.. > > Could you add a list of "currently controled kmems" section ? > > And update the list in later patch ? > > > > Thanks, > > -Kame > > > > > Hi Kame, > > Thanks for your review. > Since none of your comments are blockers, I'd prefer to send follow up > patches if you don't mind - assuming Dave won't have any restrictions > himself that would prevent him from picking this series. If I have to > resend it anyway, I'll be more than happy to address them all in my next > submission > As you like. But please clarify my comment which pointed out bugs in patch 02/10 and 06/10 aren't correct. 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org