From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Weiner Subject: Re: [PATCH] memcg: hugetlbfs basic usage accounting Date: Wed, 15 Nov 2017 07:15:08 -0500 Message-ID: <20171115121508.GA2501@cmpxchg.org> References: <20171114172429.8916-1-guro@fb.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmpxchg.org ; s=x; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lK8l8ZpLYLx41ye05YuPOxg7HQJuq6p/1ODCN4zbpEA=; b=Oc7+Xc54mrqKsfZNEGlcxbUlzY aNqERTby5FSL/Q1KhoKlRQU827QOWByhY+w0s5QoAiF4JpRoo641QTdV18Ujnw3wpQQSO3KqaVdqd uFQD4o+bF58tEg+1XEHI5+bv2tedgoAFwy7g6kfYL6e1Rcn06qGmDh4Cj+bFdCAVJtnI=; Content-Disposition: inline In-Reply-To: <20171114172429.8916-1-guro@fb.com> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Roman Gushchin Cc: linux-mm@kvack.org, Michal Hocko , Vladimir Davydov , Andrew Morton , Tejun Heo , Mike Kravetz , Dave Hansen , kernel-team@fb.com, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org On Tue, Nov 14, 2017 at 05:24:29PM +0000, Roman Gushchin wrote: > This patch implements basic accounting of memory consumption > by hugetlbfs pages for cgroup v2 memory controller. > > Cgroup v2 memory controller lacks any visibility into the > hugetlbfs memory consumption. Cgroup v1 implemented a separate > hugetlbfs controller, which provided such stats, and also > provided some control abilities. Although porting of the > hugetlbfs controller to cgroup v2 is arguable a good idea and > is outside of scope of this patch, it's very useful to have > basic stats provided by memory.stat. > > As hugetlbfs memory can easily represent a big portion of total > memory, it's important to understand who (which memcg/container) > is using it. I'm not really buying this argument. Hugetlb setups tend to be static configurations that require intimate coordination between booting the kernel with a hugetlb reservation and precisely setting up the application(s). In the few cases where you need introspection, you can check the the HugetlbPages entry in /proc//status. The minor convenience provided by adding an aggregate cgroup counter IMO doesn't outweigh the weirdness of listing a type of resource in memory.stat that isn't otherwise acknowledged or controllable as memory. -- 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 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932408AbdKOMPd (ORCPT ); Wed, 15 Nov 2017 07:15:33 -0500 Received: from gum.cmpxchg.org ([85.214.110.215]:48966 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752424AbdKOMP0 (ORCPT ); Wed, 15 Nov 2017 07:15:26 -0500 Date: Wed, 15 Nov 2017 07:15:08 -0500 From: Johannes Weiner To: Roman Gushchin Cc: linux-mm@kvack.org, Michal Hocko , Vladimir Davydov , Andrew Morton , Tejun Heo , Mike Kravetz , Dave Hansen , kernel-team@fb.com, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] memcg: hugetlbfs basic usage accounting Message-ID: <20171115121508.GA2501@cmpxchg.org> References: <20171114172429.8916-1-guro@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171114172429.8916-1-guro@fb.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 14, 2017 at 05:24:29PM +0000, Roman Gushchin wrote: > This patch implements basic accounting of memory consumption > by hugetlbfs pages for cgroup v2 memory controller. > > Cgroup v2 memory controller lacks any visibility into the > hugetlbfs memory consumption. Cgroup v1 implemented a separate > hugetlbfs controller, which provided such stats, and also > provided some control abilities. Although porting of the > hugetlbfs controller to cgroup v2 is arguable a good idea and > is outside of scope of this patch, it's very useful to have > basic stats provided by memory.stat. > > As hugetlbfs memory can easily represent a big portion of total > memory, it's important to understand who (which memcg/container) > is using it. I'm not really buying this argument. Hugetlb setups tend to be static configurations that require intimate coordination between booting the kernel with a hugetlb reservation and precisely setting up the application(s). In the few cases where you need introspection, you can check the the HugetlbPages entry in /proc//status. The minor convenience provided by adding an aggregate cgroup counter IMO doesn't outweigh the weirdness of listing a type of resource in memory.stat that isn't otherwise acknowledged or controllable as memory.