Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752293AbbLJOA3 (ORCPT ); Thu, 10 Dec 2015 09:00:29 -0500 Received: from gum.cmpxchg.org ([85.214.110.215]:48892 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751257AbbLJOA1 (ORCPT ); Thu, 10 Dec 2015 09:00:27 -0500 Date: Thu, 10 Dec 2015 09:00:12 -0500 From: Johannes Weiner To: Michal Hocko Cc: Andrew Morton , Vladimir Davydov , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 6/8] mm: memcontrol: move kmem accounting code to CONFIG_MEMCG Message-ID: <20151210140012.GA21987@cmpxchg.org> References: <1449599665-18047-1-git-send-email-hannes@cmpxchg.org> <1449599665-18047-7-git-send-email-hannes@cmpxchg.org> <20151210131718.GL19496@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151210131718.GL19496@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1391 Lines: 25 On Thu, Dec 10, 2015 at 02:17:18PM +0100, Michal Hocko wrote: > On Tue 08-12-15 13:34:23, Johannes Weiner wrote: > > The cgroup2 memory controller will account important in-kernel memory > > consumers per default. Move all necessary components to CONFIG_MEMCG. > > Hmm, that bloats the kernel also for users who are not using cgroup2 > and have CONFIG_MEMCG_KMEM disabled. Huh? The clock is ticking for them. We'll keep the original cgroup interface around for backwards compatibility as long as we think there are activer users, but this is not the time to microoptimize v1. A slight increase to kernel size is unfortunate, but I don't think this could be considered a regression in the sense that it breaks anything. I'm more concerned with cgroup2 users having to pay the excessive cost of v1-only features, like the entire soft limit implementation, charge migration, which also has its fangs in VM hotpaths, the eventfd stuff, arbitrarily-configurable usage thresholds. That's a *ton* of code. If you want to tackle kernel bloat, grouping this stuff all together and slapping a CONFIG_MEMCG_LEGACY around it would be a real step forward. -- 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/