linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Roman Gushchin <guro@fb.com>
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.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
Date: Wed, 15 Nov 2017 13:34:12 +0100	[thread overview]
Message-ID: <20171115123412.erspvvuqkeuioftt@dhcp22.suse.cz> (raw)
In-Reply-To: <20171115122306.GA16468@castle>

On Wed 15-11-17 12:23:14, Roman Gushchin wrote:
> On Wed, Nov 15, 2017 at 12:42:23PM +0100, Michal Hocko wrote:
> > On Wed 15-11-17 11:18:13, Roman Gushchin wrote:
> > > On Wed, Nov 15, 2017 at 09:35:04AM +0100, Michal Hocko wrote:
> > [...]
> > > > So my primary question is, why don't you simply allow hugetlb controller
> > > > rather than tweak stats for memcg? Is there any fundamental reason why
> > > > hugetlb controller is not v2 compatible?
> > > 
> > > I really don't know if the hugetlb controller has enough users to deserve
> > > full support in v2 interface: adding knobs like memory.hugetlb.current,
> > > memory.hugetlb.min, memory.hugetlb.high, memory.hugetlb.max, etc.
> > > 
> > > I'd be rather conservative here and avoid adding a lot to the interface
> > > without clear demand. Also, hugetlb pages are really special, and it's
> > > at least not obvious how, say, memory.high should work for it.
> > 
> > But you clearly want the hugetlb accoutning and that is what hugetlb
> > controller is for. You might not be interested in the limit enforcement
> > but that is not strictly required. So my question remains. Why don't we
> > reuse an existing infrastructure and add a new which might confuse users
> > in an extreme case?
> 
> Hm, but to use a small part of hugetlb controller infrastructure I would
> have to add a whole set of cgroup v2 controls.

And? I mean how does that differ from somebody using memcg only for stat
purposes?

> And control knobs (like memory.hugetlb.current) are much more obligatory
> than an entry in memory.stat, where we have some internal stats as well.
> 
> So, I don't really know why confusion should come from in this case?

Because you stat data that is not controlled by the controller. Just
imagine if somebody wanted to sum counters to get the resulting
accounted and enforced memory.

You are simply trying to push a square through circle without a good
reason. Unless there is a fundamental reason to not enable hugetlb
controller to v2 I would rather go that way rather than to have another
hugetlb weirdness. Enabling the controller should be a matter of
exporting knobs. Trivial thing AFAICS.
-- 
Michal Hocko
SUSE Labs

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-11-15 12:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-14 17:24 [PATCH] memcg: hugetlbfs basic usage accounting Roman Gushchin
2017-11-14 21:06 ` Tejun Heo
2017-11-15  8:35 ` Michal Hocko
2017-11-15 11:18   ` Roman Gushchin
2017-11-15 11:42     ` Michal Hocko
2017-11-15 12:23       ` Roman Gushchin
2017-11-15 12:34         ` Michal Hocko [this message]
2017-11-15 12:15 ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171115123412.erspvvuqkeuioftt@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=dave.hansen@intel.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=tj@kernel.org \
    --cc=vdavydov.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).