linux-kernel - Re: [PATCH] memcg: add support to generate the total count of children from root

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 Nov 2020 14:36:44 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Aaron Tomlin <atomlin@...hat.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>, hannes@...xchg.org,
        vdavydov.dev@...il.com, Andrew Morton <akpm@...ux-foundation.org>,
        cgroups@...r.kernel.org, linux-mm <linux-mm@...ck.org>
Subject: Re: [PATCH] memcg: add support to generate the total count of
 children from root

On Tue 24-11-20 13:27:32, Aaron Tomlin wrote:
> On Tue, 24 Nov 2020 at 11:26, Michal Hocko <mhocko@...e.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