| Message ID | 20201124105836.713371-1-atomlin@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | memcg: add support to generate the total count of children from root | expand |
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 >
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,
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,
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!
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,
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,
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", },
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(+)