From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759726AbbCDTGn (ORCPT ); Wed, 4 Mar 2015 14:06:43 -0500 Received: from gum.cmpxchg.org ([85.214.110.215]:48981 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759131AbbCDTGm (ORCPT ); Wed, 4 Mar 2015 14:06:42 -0500 Date: Wed, 4 Mar 2015 14:06:35 -0500 From: Johannes Weiner To: Michal Hocko Cc: Andrew Morton , Chen Gang <762976180@qq.com>, linux-mm@kvack.org, LKML Subject: Re: [PATCH] memcg: make CONFIG_MEMCG depend on CONFIG_MMU Message-ID: <20150304190635.GC21350@phnom.home.cmpxchg.org> References: <1425492428-27562-1-git-send-email-mhocko@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1425492428-27562-1-git-send-email-mhocko@suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 04, 2015 at 07:07:08PM +0100, Michal Hocko wrote: > CONFIG_MEMCG might be currently enabled also for !MMU architectures > which was probably an omission because Balbir had this on the TODO > list section (https://lkml.org/lkml/2008/3/16/59) > " > Only when CONFIG_MMU is enabled, is the virtual address space control > enabled. Should we do this for nommu cases as well? My suspicion is > that we don't have to. > " > I do not see any traces for !MMU requests after then. The code compiles > with !MMU but I haven't heard about anybody using it in the real life > so it is not clear to me whether it works and it is usable at all > considering how !MMU configuration is restricted. > > Let's make CONFIG_MEMCG depend on CONFIG_MMU to make our support > explicit and also to get rid of few ifdefs in the code base. > > Acked-by: Johannes Weiner > Signed-off-by: Michal Hocko Sorry about the misunderstanding, I actually acked Chen's patch. As I said, there is nothing inherent in memcg that would prevent using it on NOMMU systems except for this charges-follow-tasks feature, so I'd rather fix the compiler warning than adding this dependency. Thanks