All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Aaron Tomlin <atomlin@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	hannes@cmpxchg.org, vdavydov.dev@gmail.com,
	Andrew Morton <akpm@linux-foundation.org>,
	cgroups@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH] memcg: add support to generate the total count of children from root
Date: Tue, 24 Nov 2020 14:36:44 +0100	[thread overview]
Message-ID: <20201124133644.GA31550@dhcp22.suse.cz> (raw)
In-Reply-To: <CANfR36hyrqXjk2tL03GzCk6rn6sCD7Sd811soBsZC3dHY0h9fQ@mail.gmail.com>

On Tue 24-11-20 13:27:32, Aaron Tomlin wrote:
> On Tue, 24 Nov 2020 at 11:26, Michal Hocko <mhocko@suse.com> wrote:
> 
> > On Tue 24-11-20 10:58:36, Aaron Tomlin wrote:
> > > Each memory-controlled cgroup is assigned a unique ID and the total
> > > number of memory cgroups is limited to MEM_CGROUP_ID_MAX.
> > >
> > > This patch provides the ability to determine the number of
> > > memory cgroups from the root memory cgroup, only.
> > > A value of 1 (i.e. self count) is returned if there are no children.
> > > For example, the number of memory cgroups can be established by
> > > reading the /sys/fs/cgroup/memory/memory.total_cnt file.
> >
> 
> Hi Michal,
> 
> 
> > Could you add some explanation why is this information useful for
> > userspace? Who is going to use it and why a simple scripting on top of
> > cgroupfs is insufficient.
> >
> 
> Thank you for your feedback.
> 
> Indeed, one can use a command/script to manually calculate this.
> Having said that, one that creates a significant number of
> memory-controlled cgroups may prefer a quick, simple and reliable method
> to generate the aforementioned data, for management purposes only.
> As such, I thought this patch might be particularly useful.

This like any other user visible interface would be a much easier sell
if there was a clear usecase to justify it. I do not see anything
controversial about exporting such a value but my general take is that
we are only adding new interface when existing ones are insufficient. A
performance might be a very good reason but that would really require to
come with some real life numbers.

Thanks!
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2020-11-24 13:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 10:58 [PATCH] memcg: add support to generate the total count of children from root Aaron Tomlin
2020-11-24 10:58 ` Aaron Tomlin
2020-11-24 11:26 ` Michal Hocko
2020-11-24 11:26   ` Michal Hocko
2020-11-24 13:27   ` Aaron Tomlin
2020-11-24 13:36     ` Michal Hocko [this message]
2020-11-24 13:47       ` Aaron Tomlin
2020-11-24 13:47         ` Aaron Tomlin
2020-11-26 11:02         ` Aaron Tomlin
2020-11-24 13:36   ` Aaron Tomlin
2020-11-24 13:36     ` Aaron Tomlin
2020-11-24 13:36     ` Aaron Tomlin

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=20201124133644.GA31550@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=atomlin@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.