From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932408AbdKOMPd (ORCPT <rfc822;w@1wt.eu>);
        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 <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 15 Nov 2017 07:15:26 -0500
Date: Wed, 15 Nov 2017 07:15:08 -0500
From: Johannes Weiner <hannes@cmpxchg.org>
To: Roman Gushchin <guro@fb.com>
Cc: linux-mm@kvack.org, Michal Hocko <mhocko@kernel.org>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>, Tejun Heo <tj@kernel.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Dave Hansen <dave.hansen@intel.com>, 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: <linux-kernel.vger.kernel.org>
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/<pid>/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.