Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753923AbbETON6 (ORCPT ); Wed, 20 May 2015 10:13:58 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52708 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751609AbbETON4 (ORCPT ); Wed, 20 May 2015 10:13:56 -0400 Date: Wed, 20 May 2015 15:13:52 +0100 From: Mel Gorman To: Davidlohr Bueso Cc: Michal Hocko , Johannes Weiner , Andrew Morton , Tejun Heo , Linux-CGroups , Linux-MM , LKML Subject: Re: [PATCH 2/2] mm, memcg: Optionally disable memcg by default using Kconfig Message-ID: <20150520141352.GQ2462@suse.de> References: <1432126245-10908-1-git-send-email-mgorman@suse.de> <1432126245-10908-3-git-send-email-mgorman@suse.de> <1432129666.15239.22.camel@stgolabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1432129666.15239.22.camel@stgolabs.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1840 Lines: 45 On Wed, May 20, 2015 at 06:47:46AM -0700, Davidlohr Bueso wrote: > On Wed, 2015-05-20 at 13:50 +0100, Mel Gorman wrote: > > +config MEMCG_DEFAULT_ENABLED > > + bool "Automatically enable memory resource controller" > > + default y > > + depends on MEMCG > > + help > > + The memory controller has some overhead even if idle as resource > > + usage must be tracked in case a group is created and a process > > + migrated. As users may not be aware of this and the cgroup_disable= > > + option, this config option controls whether it is enabled by > > + default. It is assumed that someone that requires the controller > > + can find the cgroup_enable= switch. > > + > > + Say N if unsure. This is default Y to preserve oldconfig and > > + historical behaviour. > > Out of curiosity, how do you expect distros to handle this? Ideally, distros would have been able to leave this disabled by default and have the user explicitly enable it if it was required. This would have made a lot of sense when memcg had unconditional memory overhead to go with it. For distros that wanted to make the change, it would be fine to leave it disabled on fresh installs. However, if upgrading then the installer would have to also add the kernel parameter to prevent any possible regressions for the user. > I mean, this > is a pretty general functionality and customers won't want to be > changing kernels (they may or may not use memcg). iow, will this ever be > disabled? > It's not that general. It takes explicit user or sysadmin action before it's used AFAIK. -- Mel Gorman SUSE Labs -- 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/