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

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

[Aaron Tomlin]

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.

Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
---
 mm/memcontrol.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 29459a6ce1c7..a4f7cb40e233 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4535,6 +4535,19 @@ static int mem_cgroup_oom_control_write(struct cgroup_subsys_state *css,
 	return 0;
 }
 
+static int mem_cgroup_total_count_read(struct cgroup_subsys_state *css,
+				      struct cftype *cft)
+{
+	struct mem_cgroup *iter, *memcg = mem_cgroup_from_css(css);
+	int num = 0;
+
+	for_each_mem_cgroup_tree(iter, memcg)
+		num++;
+
+	/* Returns 1 (i.e. self count) if no children. */
+	return num;
+}
+
 #ifdef CONFIG_CGROUP_WRITEBACK
 
 #include <trace/events/writeback.h>
@@ -5050,6 +5063,11 @@ static struct cftype mem_cgroup_legacy_files[] = {
 		.write_u64 = mem_cgroup_oom_control_write,
 		.private = MEMFILE_PRIVATE(_OOM_TYPE, OOM_CONTROL),
 	},
+	{
+		.name = "total_cnt",
+		.flags = CFTYPE_ONLY_ON_ROOT,
+		.read_u64 = mem_cgroup_total_count_read,
+	},
 	{
 		.name = "pressure_level",
 	},
-- 
2.26.2

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

[Michal Hocko]

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.

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.

> Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
> ---
>  mm/memcontrol.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 29459a6ce1c7..a4f7cb40e233 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4535,6 +4535,19 @@ static int mem_cgroup_oom_control_write(struct cgroup_subsys_state *css,
>  	return 0;
>  }
>  
> +static int mem_cgroup_total_count_read(struct cgroup_subsys_state *css,
> +				      struct cftype *cft)
> +{
> +	struct mem_cgroup *iter, *memcg = mem_cgroup_from_css(css);
> +	int num = 0;
> +
> +	for_each_mem_cgroup_tree(iter, memcg)
> +		num++;
> +
> +	/* Returns 1 (i.e. self count) if no children. */
> +	return num;
> +}
> +
>  #ifdef CONFIG_CGROUP_WRITEBACK
>  
>  #include <trace/events/writeback.h>
> @@ -5050,6 +5063,11 @@ static struct cftype mem_cgroup_legacy_files[] = {
>  		.write_u64 = mem_cgroup_oom_control_write,
>  		.private = MEMFILE_PRIVATE(_OOM_TYPE, OOM_CONTROL),
>  	},
> +	{
> +		.name = "total_cnt",
> +		.flags = CFTYPE_ONLY_ON_ROOT,
> +		.read_u64 = mem_cgroup_total_count_read,
> +	},
>  	{
>  		.name = "pressure_level",
>  	},
> -- 
> 2.26.2
> 

-- 
Michal Hocko
SUSE Labs

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

[Aaron Tomlin]

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.

Kind regards,
-- 
Aaron Tomlin

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

[Michal Hocko]

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

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

[Aaron Tomlin]

On Tue, 24 Nov 2020 at 13:36, Michal Hocko <mhocko@suse.com> wrote:

Michal,

> 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.

Fair enough and understood.

At this stage, I unfortunately do not have such supporting data. This was only
useful in an isolated situation. Having said this, I thought that the
aforementioned interface would be helpful to others, in particular, given the
known limitation.

Kind regards,
-- 
Aaron Tomlin

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

[Aaron Tomlin]

On Tue 2020-11-24 13:47 +0000, Aaron Tomlin wrote:
> On Tue, 24 Nov 2020 at 13:36, Michal Hocko <mhocko@suse.com> wrote:
> > 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.

Michal,

> Fair enough and understood.
> 
> At this stage, I unfortunately do not have such supporting data. This was only
> useful in an isolated situation. Having said this, I thought that the
> aforementioned interface would be helpful to others, in particular, given the
> known limitation.

Furthermore, I can see that this is already provided via /proc/cgroups
(see proc_cgroupstats_show()). As such, another possibility:
the proposed interface could reliably produce the difference between the
maximum permitted memory-controlled cgroup count and the used count
(i.e. the remaining memory cgroup count, from root); albeit, I doubt that
this would be particularly useful to others i.e., the use-case would be
rather limited.


Kind regards,

-- 
Aaron Tomlin