Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753092AbbLJQZw (ORCPT ); Thu, 10 Dec 2015 11:25:52 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:36878 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751887AbbLJQZu (ORCPT ); Thu, 10 Dec 2015 11:25:50 -0500 Date: Thu, 10 Dec 2015 17:25:48 +0100 From: Michal Hocko To: Johannes Weiner Cc: Vladimir Davydov , Andrew Morton , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 7/8] mm: memcontrol: account "kmem" consumers in cgroup2 memory controller Message-ID: <20151210162548.GC11778@dhcp22.suse.cz> References: <1449599665-18047-1-git-send-email-hannes@cmpxchg.org> <1449599665-18047-8-git-send-email-hannes@cmpxchg.org> <20151209113037.GS11488@esperanza> <20151210132833.GM19496@dhcp22.suse.cz> <20151210151627.GB1431@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151210151627.GB1431@cmpxchg.org> 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: 1781 Lines: 36 On Thu 10-12-15 10:16:27, Johannes Weiner wrote: > On Thu, Dec 10, 2015 at 02:28:33PM +0100, Michal Hocko wrote: > > On Wed 09-12-15 14:30:38, Vladimir Davydov wrote: > > > From: Vladimir Davydov > > > Subject: [PATCH] mm: memcontrol: allow to disable kmem accounting for cgroup2 > > > > > > Kmem accounting might incur overhead that some users can't put up with. > > > Besides, the implementation is still considered unstable. So let's > > > provide a way to disable it for those users who aren't happy with it. > > > > Yes there will be users who do not want to pay an additional overhead > > and still accoplish what they need. > > I haven't measured the overhead lately - especially after the opt-out -> > > opt-in change so it might be much lower than my previous ~5% for kbuild > > load. > > I think switching from accounting *all* slab allocations to accounting > a list of, what, less than 20 select slabs, counts as a change > significant enough to entirely invalidate those measurements and never > bring up that number again in the context of kmem cost, don't you think? Yes, as I've said the numbers are expected to be much lower. That is one of the reasons I have acknowledged kmem enabled as a reasonable default. There will always be _special_ loads where numbers might look differently, though, and having a disabling knob is a reasonable thing to offer with a minimum maintenance overhead. And this is the argument for the inclusion of the patch from Vladimir. -- Michal Hocko 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/