Linux cgroups development
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: cgroups@vger.kernel.org
Cc: Roman Gushchin <guro@fb.com>, Tejun Heo <tj@kernel.org>,
	Zefan Li <lizefan@huawei.com>, Waiman Long <longman@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	kernel-team@fb.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [RFC 3/4] cgroup: add cgroup.stat interface with basic hierarchy stats
Date: Wed, 2 Aug 2017 17:55:31 +0100	[thread overview]
Message-ID: <20170802165532.22277-4-guro@fb.com> (raw)
In-Reply-To: <20170802165532.22277-1-guro@fb.com>

A cgroup can consume resources even after being deleted by a user.
For example, writing back dirty pages should be accounted and
limited, despite the corresponding cgroup might contain no processes
and being deleted by a user.

In the current implementation a cgroup can remain in such "dying" state
for an undefined amount of time. For instance, if a memory cgroup
contains a pge, mlocked by a process belonging to an other cgroup.

Although the lifecycle of a dying cgroup is out of user's control,
it's important to have some insight of what's going on under the hood.

In particular, it's handy to have a counter which will allow
to detect css leaks.

To solve this problem, add a cgroup.stat interface to
the base cgroup control files with the following metrics:

nr_descendants		total number of visible descendant cgroups
nr_dying_descendants	total number of dying descendant cgroups

Signed-off-by: Roman Gushchin <guro@fb.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: Waiman Long <longman@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: kernel-team@fb.com
Cc: cgroups@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/cgroup-v2.txt | 18 ++++++++++++++++++
 kernel/cgroup/cgroup.c      | 16 ++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 46ec3f76211c..dc44785dc0fa 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -868,6 +868,24 @@ All cgroup core files are prefixed with "cgroup."
 	If the actual descent depth is equal or larger,
 	an attempt to create a new child cgroup will fail.
 
+  cgroup.stat
+	A read-only flat-keyed file with the following entries:
+
+	  nr_descendants
+		Total number of visible descendant cgroups.
+
+	  nr_dying_descendants
+		Total number of dying descendant cgroups. A cgroup becomes
+		dying after being deleted by a user. The cgroup will remain
+		in dying state for some time undefined time (which can depend
+		on system load) before being completely destroyed.
+
+		A process can't enter a dying cgroup under any circumstances,
+		a dying cgroup can't revive.
+
+		A dying cgroup can consume system resources not exceeding
+		limits, which were active at the moment of cgroup deletion.
+
 
 Controllers
 ===========
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 9d53d69e44bb..f58e1fe8bebd 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3304,6 +3304,18 @@ static int cgroup_events_show(struct seq_file *seq, void *v)
 	return 0;
 }
 
+static int cgroup_stats_show(struct seq_file *seq, void *v)
+{
+	struct cgroup *cgroup = seq_css(seq)->cgroup;
+
+	seq_printf(seq, "nr_descendants %d\n",
+		   cgroup->nr_descendants);
+	seq_printf(seq, "nr_dying_descendants %d\n",
+		   cgroup->nr_dying_descendants);
+
+	return 0;
+}
+
 static int cgroup_file_open(struct kernfs_open_file *of)
 {
 	struct cftype *cft = of->kn->priv;
@@ -4407,6 +4419,10 @@ static struct cftype cgroup_base_files[] = {
 		.seq_show = cgroup_max_depth_show,
 		.write = cgroup_max_depth_write,
 	},
+	{
+		.name = "cgroup.stat",
+		.seq_show = cgroup_stats_show,
+	},
 	{ }	/* terminate */
 };
 
-- 
2.13.3


  parent reply	other threads:[~2017-08-02 16:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 16:55 [RFC 0/4] cgroup hierarchy controls and stats Roman Gushchin
2017-08-02 16:55 ` [RFC 1/4] cgroup: keep track of number of descent cgroups Roman Gushchin
2017-08-02 16:55 ` [RFC 2/4] cgroup: implement hierarchy limits Roman Gushchin
     [not found]   ` <20170802165532.22277-3-guro-b10kYP2dOMg@public.gmane.org>
2017-08-02 18:44     ` Tejun Heo
2017-08-02 18:55       ` Roman Gushchin
2017-08-02 16:55 ` Roman Gushchin [this message]
2017-08-02 16:55 ` [RFC 4/4] cgroup: re-use the parent pointer in cgroup_destroy_locked() Roman Gushchin
2017-08-02 18:50   ` Tejun Heo
     [not found] ` <20170802165532.22277-1-guro-b10kYP2dOMg@public.gmane.org>
2017-08-02 19:06   ` [RFC 0/4] cgroup hierarchy controls and stats Tejun Heo

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=20170802165532.22277-4-guro@fb.com \
    --to=guro@fb.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=longman@redhat.com \
    --cc=tj@kernel.org \
    /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