Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999Ab2JQWLp (ORCPT ); Wed, 17 Oct 2012 18:11:45 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:57020 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750895Ab2JQWLo (ORCPT ); Wed, 17 Oct 2012 18:11:44 -0400 Date: Wed, 17 Oct 2012 15:11:42 -0700 From: Andrew Morton To: Glauber Costa Cc: , , Mel Gorman , Tejun Heo , Michal Hocko , Johannes Weiner , , Christoph Lameter , David Rientjes , Pekka Enberg , , Subject: Re: [PATCH v5 00/14] kmem controller for memcg. Message-Id: <20121017151142.71e1f3c5.akpm@linux-foundation.org> In-Reply-To: <1350382611-20579-1-git-send-email-glommer@parallels.com> References: <1350382611-20579-1-git-send-email-glommer@parallels.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2070 Lines: 50 On Tue, 16 Oct 2012 14:16:37 +0400 Glauber Costa wrote: > ... > > A general explanation of what this is all about follows: > > The kernel memory limitation mechanism for memcg concerns itself with > disallowing potentially non-reclaimable allocations to happen in exaggerate > quantities by a particular set of processes (cgroup). Those allocations could > create pressure that affects the behavior of a different and unrelated set of > processes. > > Its basic working mechanism is to annotate some allocations with the > _GFP_KMEMCG flag. When this flag is set, the current process allocating will > have its memcg identified and charged against. When reaching a specific limit, > further allocations will be denied. The need to set _GFP_KMEMCG is rather unpleasing, and makes one wonder "why didn't it just track all allocations". Does this mean that over time we can expect more sites to get the _GFP_KMEMCG tagging? If so, are there any special implications, or do we just go in, do the one-line patch and expect everything to work? If so, why don't we go in and do that tagging right now? And how *accurate* is the proposed code? What percentage of kernel memory allocations are unaccounted, typical case and worst case? All sorts of questions come to mind over this decision, but it was unexplained. It should be, please. A lot! > > ... > > Limits lower than > the user limit effectively means there is a separate kernel memory limit that > may be reached independently than the user limit. Values equal or greater than > the user limit implies only that kernel memory is tracked. This provides a > unified vision of "maximum memory", be it kernel or user memory. > I'm struggling to understand that text much at all. Reading the Documentation/cgroups/memory.txt patch helped. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/