From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758252Ab2IZTeX (ORCPT ); Wed, 26 Sep 2012 15:34:23 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:62490 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756609Ab2IZTeV (ORCPT ); Wed, 26 Sep 2012 15:34:21 -0400 Date: Wed, 26 Sep 2012 12:34:17 -0700 From: Tejun Heo To: Glauber Costa Cc: Michal Hocko , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, devel@openvz.org, linux-mm@kvack.org, Suleiman Souhlal , Frederic Weisbecker , Mel Gorman , David Rientjes , Johannes Weiner Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Message-ID: <20120926193417.GJ12544@google.com> References: <1347977050-29476-1-git-send-email-glommer@parallels.com> <1347977050-29476-5-git-send-email-glommer@parallels.com> <20120926140347.GD15801@dhcp22.suse.cz> <20120926163648.GO16296@google.com> <50633D24.6020002@parallels.com> <50634105.8060302@parallels.com> <20120926180124.GA12544@google.com> <50634FC9.4090609@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50634FC9.4090609@parallels.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Sep 26, 2012 at 10:56:09PM +0400, Glauber Costa wrote: > For me, it is the other way around: it makes perfect sense to have a > per-subtree selection of features where it doesn't hurt us, provided it > is hierarchical. For the mere fact that not every application is > interested in this (Michal is the one that is being so far more vocal > about this not being needed in some use cases), and it is perfectly > valid to imagine such applications would coexist. > > So given the flexibility it brings, the real question is, as I said, > backwards: what is it necessary to make it a global switch ? Because it hurts my head and it's better to keep things simple. We're planning to retire .use_hierarhcy in sub hierarchies and I'd really like to prevent another fiasco like that unless there absolutely is no way around it. Flexibility where necessary is fine but let's please try our best to avoid over-designing things. We've been far too good at getting lost in flexbility maze. Michal, care to chime in? Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx165.postini.com [74.125.245.165]) by kanga.kvack.org (Postfix) with SMTP id 2424E6B0062 for ; Wed, 26 Sep 2012 15:34:22 -0400 (EDT) Received: by pbbrq2 with SMTP id rq2so2689954pbb.14 for ; Wed, 26 Sep 2012 12:34:21 -0700 (PDT) Date: Wed, 26 Sep 2012 12:34:17 -0700 From: Tejun Heo Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Message-ID: <20120926193417.GJ12544@google.com> References: <1347977050-29476-1-git-send-email-glommer@parallels.com> <1347977050-29476-5-git-send-email-glommer@parallels.com> <20120926140347.GD15801@dhcp22.suse.cz> <20120926163648.GO16296@google.com> <50633D24.6020002@parallels.com> <50634105.8060302@parallels.com> <20120926180124.GA12544@google.com> <50634FC9.4090609@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50634FC9.4090609@parallels.com> Sender: owner-linux-mm@kvack.org List-ID: To: Glauber Costa Cc: Michal Hocko , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, devel@openvz.org, linux-mm@kvack.org, Suleiman Souhlal , Frederic Weisbecker , Mel Gorman , David Rientjes , Johannes Weiner Hello, On Wed, Sep 26, 2012 at 10:56:09PM +0400, Glauber Costa wrote: > For me, it is the other way around: it makes perfect sense to have a > per-subtree selection of features where it doesn't hurt us, provided it > is hierarchical. For the mere fact that not every application is > interested in this (Michal is the one that is being so far more vocal > about this not being needed in some use cases), and it is perfectly > valid to imagine such applications would coexist. > > So given the flexibility it brings, the real question is, as I said, > backwards: what is it necessary to make it a global switch ? Because it hurts my head and it's better to keep things simple. We're planning to retire .use_hierarhcy in sub hierarchies and I'd really like to prevent another fiasco like that unless there absolutely is no way around it. Flexibility where necessary is fine but let's please try our best to avoid over-designing things. We've been far too good at getting lost in flexbility maze. Michal, care to chime in? Thanks. -- tejun -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Date: Wed, 26 Sep 2012 12:34:17 -0700 Message-ID: <20120926193417.GJ12544@google.com> References: <1347977050-29476-1-git-send-email-glommer@parallels.com> <1347977050-29476-5-git-send-email-glommer@parallels.com> <20120926140347.GD15801@dhcp22.suse.cz> <20120926163648.GO16296@google.com> <50633D24.6020002@parallels.com> <50634105.8060302@parallels.com> <20120926180124.GA12544@google.com> <50634FC9.4090609@parallels.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ogrZzy+yM1Kasos3/MLTteG7DeUQoSXG9YHpuiN3D9o=; b=M3vWsC6Kyxn3YdfRkM8ygaAkD9aUk38aCUnl/K/a48U7iOMdO/c8F7t6hR8gREMJ1c MG4GDJ3gxW5dvpYBfYOzFZ1KxtU15eY63tBacdlaM+ZFlrRFWebpwJSAHQNm4PqJBADl WFrH7gv2ZHs5ZQl4aYsd14yoozVQ9+DOnjXsUOH+5TCbJazakodmjFobHP77DuzFmNIw k5qsekC4FdK2rO902KcJ5rOZIYPLZB1GqxA9Lyf7XSsuK2ivqB1bxWnbXDfHZDVsHzGz Q3HWA4I9AFmpeAT3R/vMzdXlk9wqediDKZXAW9GlwTFbcCCzyAXkkUM2gbqgAnBCkYP2 k5yw== Content-Disposition: inline In-Reply-To: <50634FC9.4090609-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Glauber Costa Cc: Michal Hocko , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Suleiman Souhlal , Frederic Weisbecker , Mel Gorman , David Rientjes , Johannes Weiner Hello, On Wed, Sep 26, 2012 at 10:56:09PM +0400, Glauber Costa wrote: > For me, it is the other way around: it makes perfect sense to have a > per-subtree selection of features where it doesn't hurt us, provided it > is hierarchical. For the mere fact that not every application is > interested in this (Michal is the one that is being so far more vocal > about this not being needed in some use cases), and it is perfectly > valid to imagine such applications would coexist. > > So given the flexibility it brings, the real question is, as I said, > backwards: what is it necessary to make it a global switch ? Because it hurts my head and it's better to keep things simple. We're planning to retire .use_hierarhcy in sub hierarchies and I'd really like to prevent another fiasco like that unless there absolutely is no way around it. Flexibility where necessary is fine but let's please try our best to avoid over-designing things. We've been far too good at getting lost in flexbility maze. Michal, care to chime in? Thanks. -- tejun