Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760693Ab2FGKzi (ORCPT ); Thu, 7 Jun 2012 06:55:38 -0400 Received: from mx2.parallels.com ([64.131.90.16]:37942 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932227Ab2FGKzg (ORCPT ); Thu, 7 Jun 2012 06:55:36 -0400 Message-ID: <4FD08813.9070307@parallels.com> Date: Thu, 7 Jun 2012 14:53:07 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Frederic Weisbecker CC: , , , , Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , , David Rientjes Subject: Re: [PATCH v3 00/28] kmem limitation for memcg References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <20120607102604.GE19842@somewhere.redhat.com> In-Reply-To: <20120607102604.GE19842@somewhere.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2598 Lines: 56 On 06/07/2012 02:26 PM, Frederic Weisbecker wrote: > On Fri, May 25, 2012 at 05:03:20PM +0400, Glauber Costa wrote: >> Hello All, >> >> This is my new take for the memcg kmem accounting. This should merge >> all of the previous comments from you, plus fix a bunch of bugs. >> >> At this point, I consider the series pretty mature. Since last submission >> 2 weeks ago, I focused on broadening the testing coverage. Some bugs were >> fixed, but that of course doesn't mean no bugs exist. >> >> I believe some of the early patches here are already in some trees around. >> I don't know who should pick this, so if everyone agrees with what's in here, >> please just ack them and tell me which tree I should aim for (-mm? Hocko's?) >> and I'll rebase it. >> >> I should point out again that most, if not all, of the code in the caches >> are wrapped in static_key areas, meaning they will be completely patched out >> until the first limit is set. Enabling and disabling of static_keys incorporate >> the last fixes for sock memcg, and should be pretty robust. >> >> I also put a lot of effort, as you will all see, in the proper separation >> of the patches, so the review process is made as easy as the complexity of >> the work allows to. > > So I believe that if I want to implement a per kernel stack accounting/limitation, > I need to work on top of your patchset. > > What do you think about having some sub kmem accounting based on the caches? > For example there could be a specific accounting per kmem cache. > > Like if we use a specific kmem cache to allocate the kernel stack > (as is done by some archs but I can generalize that for those who want > kernel stack accounting), allocations are accounted globally in the memcg as > done in your patchset but also on a seperate counter only for this kmem cache > on the memcg, resulting in a kmem.stack.usage somewhere. > > The concept of per kmem cache accounting can be expanded more for any > kind of finegrained kmem accounting. > > Thoughts? I believe a general separation is too much, and will lead to knob explosion. So I don't think it is a good idea. Now, for the stack itself, it can be justified. The question that remains to be answered is: Why do you need to set the stack value separately? Isn't accounting the stack value, and limiting against the global kmem limit enough? -- 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/