cgroup, sched: cgroup2 basic resource accounting

In cgroup1, while cpuacct isn't actually controlling any resources, it is a separate controller due to combinaton of two factors -
1. enabling cpu controller has significant side effects, and 2. we have to pick one of the hierarchies to account CPU usages on. cpuacct controller is effectively used to designate a hierarchy to track CPU usages on.

cgroup2's unified hierarchy removes the second reason and we can account basic CPU usages by default. While we can use cpuacct for this purpose, both its interface and implementation leave a lot to be desired - it collects and exposes two sources of truth which don't agree with each other and some of the exposed statistics don't make much sense. Also, it propagates all the way up the hierarchy on each accounting event which is unnecessary.

This patch adds basic resource accounting mechanism to cgroup2's unified hierarchy and accounts CPU usages using it.

* All accountings are done per-cpu and don't propagate immediately. It just bumps the per-cgroup per-cpu counters and links to the parent's updated list if not already on it.

* On a read, the per-cpu counters are collected into the global ones and then propagated upwards. Only the per-cpu counters which have changed since the last read are propagated.

* CPU usage stats are collected and shown in "cgroup.stat" with "cpu." prefix. Total usage is collected from scheduling events. User/sys breakdown is sourced from tick sampling and adjusted to the usage using cputime_adjuts().

This keeps the accounting side hot path O(1) and per-cpu and the read side O(nr_updated_since_last_read).

Signed-off-by Tejun Heo <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Li Zefan <[email protected]>

Cc Johannes Weiner <[email protected]>

---
 Documentation/cgroup-v2.txt     |   9 ++
 include/linux/cgroup-defs.h     |  47 ++++++
 include/linux/cgroup.h          |  22 +++
 kernel/cgroup/Makefile          |   2 +-
 kernel/cgroup/cgroup-internal.h |   8 +
 kernel/cgroup/cgroup.c          |  24 ++-
 kernel/cgroup/stat.c            | 333 ++++++++++++++++++++++++++++++++++++++++
 7 files changed, 442 insertions(+), 3 deletions(-)
 create mode 100644 kernel/cgroup/stat.c

Documentation/cgroup-v2.txt +9 -0

index dc44785..3f82169 100644
@@ -886,6 +886,15 @@ All cgroup core files are prefixed with "cgroup."
 		A dying cgroup can consume system resources not exceeding
 		limits, which were active at the moment of cgroup deletion.
 
+	  cpu.usage_usec
+		CPU time consumed in the subtree.
+
+	  cpu.user_usec
+		User CPU time consumed in the subtree.
+
+	  cpu.system_usec
+		System CPU time consumed in the subtree.
+
 
 Controllers
 ===========

include/linux/cgroup-defs.h +47 -0

index 59e4ad9..17da9c8 100644
@@ -16,6 +16,7 @@
 #include <linux/refcount.h>
 #include <linux/percpu-refcount.h>
 #include <linux/percpu-rwsem.h>
+#include <linux/u64_stats_sync.h>
 #include <linux/workqueue.h>
 #include <linux/bpf-cgroup.h>
 

@@ -249,6 +250,47 @@ struct css_set {
 	struct rcu_head rcu_head;
 };
 
+/*
+ * cgroup basic resource usage statistics.  Accounting is done per-cpu in
+ * cgroup_cpu_stat which is then lazily propagated up the hierarchy on
+ * reads.  The propagation is selective - only the cgroup_cpu_stats which
+ * have been updated since the last propagation are propagated.
+ */
+struct cgroup_cpu_stat {
+	/*
+	 * ->sync protects all the current counters.  These are the only
+	 * fields which get updated in the hot path.
+	 */
+	struct u64_stats_sync sync;
+	struct task_cputime cputime;
+
+	/*
+	 * Snapshots at the last reading.  These are used to calculate the
+	 * deltas to propagate to the global counters.
+	 */
+	struct task_cputime last_cputime;
+
+	/*
+	 * Child cgroups with stat updates on this cpu since the last read
+	 * are linked on the parent's ->updated_children through
+	 * ->updated_next.
+	 *
+	 * In addition to being more compact, singly-linked list pointing
+	 * to the cgroup makes it unnecessary for each per-cpu struct to
+	 * point back to the associated cgroup.
+	 *
+	 * Protected by per-cpu cgroup_cpu_stat_lock.
+	 */
+	struct cgroup *updated_children;	/* terminated by self cgroup */
+	struct cgroup *updated_next;		/* NULL iff not on the list */
+};
+
+struct cgroup_stat {
+	/* per-cpu statistics are collected into the folowing global counters */
+	struct task_cputime cputime;
+	struct prev_cputime prev_cputime;
+};
+
 struct cgroup {
 	/* self css with NULL ->ss, points back to this cgroup */
 	struct cgroup_subsys_state self;

@@ -348,6 +390,11 @@ struct cgroup {
 	 */
 	struct cgroup *dom_cgrp;
 
+	/* cgroup basic resource statistics */
+	struct cgroup_cpu_stat __percpu *cpu_stat;
+	struct cgroup_stat pending_stat;	/* pending from children */
+	struct cgroup_stat stat;
+
 	/*
 	 * list of pidlists, up to two for each namespace (one for procs, one
 	 * for tasks); created on demand.

include/linux/cgroup.h +22 -0

index f395e02..4c82212 100644
@@ -689,17 +689,39 @@ static inline void cpuacct_account_field(struct task_struct *tsk, int index,
 					 u64 val) {}
 #endif
 
+void cgroup_stat_show_cputime(struct seq_file *seq, const char *prefix);
+
+void __cgroup_account_cputime(struct cgroup *cgrp, u64 delta_exec);
+void __cgroup_account_cputime_field(struct cgroup *cgrp,
+				    enum cpu_usage_stat index, u64 delta_exec);
+
 static inline void cgroup_account_cputime(struct task_struct *task,
 					  u64 delta_exec)
 {
+	struct cgroup *cgrp;
+
 	cpuacct_charge(task, delta_exec);
+
+	rcu_read_lock();
+	cgrp = task_dfl_cgroup(task);
+	if (cgroup_parent(cgrp))
+		__cgroup_account_cputime(cgrp, delta_exec);
+	rcu_read_unlock();
 }
 
 static inline void cgroup_account_cputime_field(struct task_struct *task,
 						enum cpu_usage_stat index,
 						u64 delta_exec)
 {
+	struct cgroup *cgrp;
+
 	cpuacct_account_field(task, index, delta_exec);
+
+	rcu_read_lock();
+	cgrp = task_dfl_cgroup(task);
+	if (cgroup_parent(cgrp))
+		__cgroup_account_cputime_field(cgrp, index, delta_exec);
+	rcu_read_unlock();
 }
 
 #else	/* CONFIG_CGROUPS */

kernel/cgroup/Makefile +1 -1

index ce693cc..0acee61 100644
@@ -1,4 +1,4 @@
-obj-y := cgroup.o namespace.o cgroup-v1.o
+obj-y := cgroup.o stat.o namespace.o cgroup-v1.o
 
 obj-$(CONFIG_CGROUP_FREEZER) += freezer.o
 obj-$(CONFIG_CGROUP_PIDS) += pids.o

kernel/cgroup/cgroup-internal.h +8 -0

index c167a40..f17da09 100644
@@ -197,6 +197,14 @@ int cgroup_show_path(struct seq_file *sf, struct kernfs_node *kf_node,
 int cgroup_task_count(const struct cgroup *cgrp);
 
 /*
+ * stat.c
+ */
+void cgroup_stat_flush(struct cgroup *cgrp);
+int cgroup_stat_init(struct cgroup *cgrp);
+void cgroup_stat_exit(struct cgroup *cgrp);
+void cgroup_stat_boot(void);
+
+/*
  * namespace.c
  */
 extern const struct proc_ns_operations cgroupns_operations;

kernel/cgroup/cgroup.c +22 -2

index c038ccf..a399a55 100644
@@ -142,12 +142,14 @@ static struct static_key_true *cgroup_subsys_on_dfl_key[] = {
 };
 #undef SUBSYS
 
+static DEFINE_PER_CPU(struct cgroup_cpu_stat, cgrp_dfl_root_cpu_stat);
+
 /*
  * The default hierarchy, reserved for the subsystems that are otherwise
  * unattached - it never has more than a single cgroup, and all tasks are
  * part of that cgroup.
  */
-struct cgroup_root cgrp_dfl_root;
+struct cgroup_root cgrp_dfl_root = { .cgrp.cpu_stat = &cgrp_dfl_root_cpu_stat };
 EXPORT_SYMBOL_GPL(cgrp_dfl_root);
 
 /*

@@ -3296,6 +3298,8 @@ static int cgroup_stat_show(struct seq_file *seq, void *v)
 	seq_printf(seq, "nr_dying_descendants %d\n",
 		   cgroup->nr_dying_descendants);
 
+	cgroup_stat_show_cputime(seq, "cpu.");
+
 	return 0;
 }
 

@@ -4466,6 +4470,8 @@ static void css_free_work_fn(struct work_struct *work)
 			 */
 			cgroup_put(cgroup_parent(cgrp));
 			kernfs_put(cgrp->kn);
+			if (cgroup_on_dfl(cgrp))
+				cgroup_stat_exit(cgrp);
 			kfree(cgrp);
 		} else {
 			/*

@@ -4510,6 +4516,9 @@ static void css_release_work_fn(struct work_struct *work)
 		/* cgroup release path */
 		trace_cgroup_release(cgrp);
 
+		if (cgroup_on_dfl(cgrp))
+			cgroup_stat_flush(cgrp);
+
 		for (tcgrp = cgroup_parent(cgrp); tcgrp;
 		     tcgrp = cgroup_parent(tcgrp))
 			tcgrp->nr_dying_descendants--;

@@ -4696,6 +4705,12 @@ static struct cgroup *cgroup_create(struct cgroup *parent)
 	if (ret)
 		goto out_free_cgrp;
 
+	if (cgroup_on_dfl(parent)) {
+		ret = cgroup_stat_init(cgrp);
+		if (ret)
+			goto out_cancel_ref;
+	}
+
 	/*
 	 * Temporarily set the pointer to NULL, so idr_find() won't return
 	 * a half-baked cgroup.

@@ -4703,7 +4718,7 @@ static struct cgroup *cgroup_create(struct cgroup *parent)
 	cgrp->id = cgroup_idr_alloc(&root->cgroup_idr, NULL, 2, 0, GFP_KERNEL);
 	if (cgrp->id < 0) {
 		ret = -ENOMEM;
-		goto out_cancel_ref;
+		goto out_stat_exit;
 	}
 
 	init_cgroup_housekeeping(cgrp);

@@ -4752,6 +4767,9 @@ static struct cgroup *cgroup_create(struct cgroup *parent)
 
 	return cgrp;
 
+out_stat_exit:
+	if (cgroup_on_dfl(parent))
+		cgroup_stat_exit(cgrp);
 out_cancel_ref:
 	percpu_ref_exit(&cgrp->self.refcnt);
 out_free_cgrp:

@@ -5146,6 +5164,8 @@ int __init cgroup_init(void)
 	BUG_ON(cgroup_init_cftypes(NULL, cgroup_base_files));
 	BUG_ON(cgroup_init_cftypes(NULL, cgroup1_base_files));
 
+	cgroup_stat_boot();
+
 	/*
 	 * The latency of the synchronize_sched() is too high for cgroups,
 	 * avoid it at the cost of forcing all readers into the slow path.

kernel/cgroup/stat.c new file +0 -0

new file mode 100644
index 0000000..19a10b2

kernel/cgroup/stat.c new file +60 -0

+
+static struct cgroup_cpu_stat *cgroup_cpu_stat(struct cgroup *cgrp, int cpu)
+{
+	return per_cpu_ptr(cgrp->cpu_stat, cpu);
+}
+
+/**
+ * cgroup_cpu_stat_updated - keep track of updated cpu_stat
+ * @cgrp: target cgroup
+ * @cpu: cpu on which cpu_stat was updated
+ *
+ * @cgrp's cpu_stat on @cpu was updated.  Put it on the parent's matching
+ * cpu_stat->updated_children list.
+ */
+static void cgroup_cpu_stat_updated(struct cgroup *cgrp, int cpu)
+{
+	raw_spinlock_t *cpu_lock = per_cpu_ptr(&cgroup_cpu_stat_lock, cpu);
+	struct cgroup *parent;
+	unsigned long flags;
+
+	/*
+	 * Speculative already-on-list test.  This may race leading to
+	 * temporary inaccuracies, which is fine.
+	 *
+	 * Because @parent's updated_children is terminated with @parent
+	 * instead of NULL, we can tell whether @cgrp is on the list by
+	 * testing the next pointer for NULL.
+	 */
+	if (cgroup_cpu_stat(cgrp, cpu)->updated_next)
+		return;
+
+	raw_spin_lock_irqsave(cpu_lock, flags);
+
+	/* put @cgrp and all ancestors on the corresponding updated lists */
+	for (parent = cgroup_parent(cgrp); parent;
+	     cgrp = parent, parent = cgroup_parent(cgrp)) {
+		struct cgroup_cpu_stat *cstat = cgroup_cpu_stat(cgrp, cpu);
+		struct cgroup_cpu_stat *pcstat = cgroup_cpu_stat(parent, cpu);
+
+		/*
+		 * Both additions and removals are bottom-up.  If a cgroup
+		 * is already in the tree, all ancestors are.
+		 */
+		if (cstat->updated_next)
+			break;
+
+		cstat->updated_next = pcstat->updated_children;
+		pcstat->updated_children = cgrp;
+	}
+
+	raw_spin_unlock_irqrestore(cpu_lock, flags);
+}
+
+/**
+ * cgroup_cpu_stat_next_updated - iterate cpu_stat updated tree
+ * @pos: current position
+ * @root: root of the tree to traversal
+ * @cpu: target cpu
+ *
+ * Walks the udpated cpu_stat tree on @cpu from @root.  %NULL @pos starts

Quoted 4 lines

* CPU usage stats are collected and shown in "cgroup.stat" with "cpu." prefix. Total usage is collected from scheduling events. User/sys breakdown is sourced from tick sampling and adjusted to the usage using cputime_adjuts().

Typo: cputime_adjust()

kernel/cgroup/stat.c line 6

Quoted 2 lines

kernel/cgroup/stat.c new file +2 -0

+static DEFINE_MUTEX(cgroup_stat_mutex);
+static DEFINE_PER_CPU(raw_spinlock_t, cgroup_cpu_stat_lock);

If the hierarchy is large enough and the stat data hasn't been read recently, it may take a while to accumulate all the stat data even for one cpu in cgroup_stat_flush_locked(). So I think it will make more sense to use regular spinlock_t instead of raw_spinlock_t.

kernel/cgroup/stat.c line 76

Quoted 2 lines

kernel/cgroup/stat.c new file +2 -0

+static struct cgroup *cgroup_cpu_stat_next_updated(struct cgroup *pos,
+						   struct cgroup *root, int cpu)

This function is trying to unwind one cgrp from the updated_children and updated_next linkage. It is somewhat like the opposite of cgroup_cpu_stat_updated(). I just feel like its name isn't intuitive enough to convey what it is doing. Maybe use name like cgroup_cpu_stat_unlink_one() to match cgroup_cpu_stat_flush_one().

Hello, Waiman.

Quoted 5 lines · Waiman Long

Quoted 4 lines

* CPU usage stats are collected and shown in "cgroup.stat" with "cpu." prefix. Total usage is collected from scheduling events. User/sys breakdown is sourced from tick sampling and adjusted to the usage using cputime_adjuts().

Typo: cputime_adjust()

Oops, will fix.

Quoted 6 lines

kernel/cgroup/stat.c line 6

Quoted 2 lines

kernel/cgroup/stat.c new file +2 -0

+static DEFINE_MUTEX(cgroup_stat_mutex);
+static DEFINE_PER_CPU(raw_spinlock_t, cgroup_cpu_stat_lock);

If the hierarchy is large enough and the stat data hasn't been read recently, it may take a while to accumulate all the stat data even for one cpu in cgroup_stat_flush_locked(). So I think it will make more sense to use regular spinlock_t instead of raw_spinlock_t.

They need to be raw spinlocks because the accounting side may grab them while scheduling. If the accumulating latency becomes problematic, we can test for need_resched and spin_needbreak and break out as necessary. The iteration logic is built to allow that and an earlier revision actually did that but I wasn't sure whether it's actually necessary and removed it for simplicity.

If the latency ever becomes a problem, resurrecting that isn't difficult at all.

Quoted 7 lines

kernel/cgroup/stat.c line 76

Quoted 2 lines

kernel/cgroup/stat.c new file +2 -0

+static struct cgroup *cgroup_cpu_stat_next_updated(struct cgroup *pos,
+						   struct cgroup *root, int cpu)

This function is trying to unwind one cgrp from the updated_children and updated_next linkage. It is somewhat like the opposite of cgroup_cpu_stat_updated(). I just feel like its name isn't intuitive enough to convey what it is doing. Maybe use name like cgroup_cpu_stat_unlink_one() to match cgroup_cpu_stat_flush_one().

Hmm... the name comes from it being an iterator - most interators are named _next. But, yeah, the name doesn't signifiy that it unlinks as it goes along. I'll rename it to cgroup_cpu_stat_pop_updated().

In cgroup1, while cpuacct isn't actually controlling any resources, it is a separate controller due to combinaton of two factors -

Quoted 2 lines · Tejun Heo

In cgroup1, while cpuacct isn't actually controlling any resources, it is a separate controller due to combinaton of two factors -

s/combinaton/combination

kernel/cgroup/cgroup.c static void css_free_work_fn(struct work_struct *work) · line 4474

Quoted 6 lines

kernel/cgroup/cgroup.c +2 -0

@@ -4466,6 +4470,8 @@ static void css_free_work_fn(struct work_struct *work)
 			 */
 			cgroup_put(cgroup_parent(cgrp));
 			kernfs_put(cgrp->kn);
+			if (cgroup_on_dfl(cgrp))
+				cgroup_stat_exit(cgrp);

It looks like this "if (cgroup_on_dfl(cgrp))" works here and further similar to "#ifdef CGROUP_V2". I wonder, if it's better to move this check into the calling function: cgroup_stat_exit() in this case.

Review static void css_free_work_fn(struct work_struct *work) · line 4476

Quoted 2 lines

(quoted diff) +2 -0

+void cgroup_stat_show_cputime(struct seq_file *seq, const char *prefix)
+{

What are any other possible prefix values except "cpu."?

Quoted 4 lines

kernel/cgroup/stat.c new file +4 -0

+void __init cgroup_stat_boot(void)
+{
+	int cpu;
+

kernel/cgroup/stat.c line 332

Quoted 4 lines

kernel/cgroup/stat.c new file +4 -0

+	for_each_possible_cpu(cpu)
+		raw_spin_lock_init(per_cpu_ptr(&cgroup_cpu_stat_lock, cpu));
+
+	WARN_ON(cgroup_stat_init(&cgrp_dfl_root.cgrp));

I'm not sure WARN_ON() is enough here: if cgroup_stat_init() returned -ENOMEM, the following OOPS is not avoidable, as you don't check cpu_stat pointer. But it's very unlikely, of course.

kernel/cgroup/stat.c new file +61 -0

+/**
+ * cgroup_cpu_stat_updated - keep track of updated cpu_stat
+ * @cgrp: target cgroup
+ * @cpu: cpu on which cpu_stat was updated
+ *
+ * @cgrp's cpu_stat on @cpu was updated.  Put it on the parent's matching
+ * cpu_stat->updated_children list.
+ */
+static void cgroup_cpu_stat_updated(struct cgroup *cgrp, int cpu)
+{
+	raw_spinlock_t *cpu_lock = per_cpu_ptr(&cgroup_cpu_stat_lock, cpu);
+	struct cgroup *parent;
+	unsigned long flags;
+
+	/*
+	 * Speculative already-on-list test.  This may race leading to
+	 * temporary inaccuracies, which is fine.
+	 *
+	 * Because @parent's updated_children is terminated with @parent
+	 * instead of NULL, we can tell whether @cgrp is on the list by
+	 * testing the next pointer for NULL.
+	 */
+	if (cgroup_cpu_stat(cgrp, cpu)->updated_next)
+		return;
+
+	raw_spin_lock_irqsave(cpu_lock, flags);
+
+	/* put @cgrp and all ancestors on the corresponding updated lists */
+	for (parent = cgroup_parent(cgrp); parent;
+	     cgrp = parent, parent = cgroup_parent(cgrp)) {
+		struct cgroup_cpu_stat *cstat = cgroup_cpu_stat(cgrp, cpu);
+		struct cgroup_cpu_stat *pcstat = cgroup_cpu_stat(parent, cpu);
+
+		/*
+		 * Both additions and removals are bottom-up.  If a cgroup
+		 * is already in the tree, all ancestors are.
+		 */
+		if (cstat->updated_next)
+			break;
+
+		cstat->updated_next = pcstat->updated_children;
+		pcstat->updated_children = cgrp;
+	}
+
+	raw_spin_unlock_irqrestore(cpu_lock, flags);
+}
 
+static struct cgroup_cpu_stat *cgroup_cpu_stat_account_begin(struct cgroup *cgrp)
+{
+	struct cgroup_cpu_stat *cstat;
+
+	cstat = get_cpu_ptr(cgrp->cpu_stat);
+	u64_stats_update_begin(&cstat->sync);
+	return cstat;
+}
+
+static void cgroup_cpu_stat_account_end(struct cgroup *cgrp,
+					struct cgroup_cpu_stat *cstat)
+{
+	u64_stats_update_end(&cstat->sync);
+	cgroup_cpu_stat_updated(cgrp, smp_processor_id());
+	put_cpu_ptr(cstat);

So I mostly like. On accounting it only adds to the immediate cgroup (if it has a parent, aka !root).

On update it does a DFS of all sub-groups and propagates the deltas up to the requested group.

What I don't get is why you need cgroup_cpu_stat_updated(). That is, I see you use it to keep the keep the DFS 'stack' up-to-date, but what I don't see is why you'd need that.

Have a look at walk_tg_tree_from(), I think we can do something like that on struct cgroup_subsys_state, it has that children list and the parent pointer.

And yes, walk_tg_tree_from() is tricky, it always takes a fair while to remember how it works.

Hello, Peter.

Quoted 5 lines · Peter Zijlstra

So I mostly like. On accounting it only adds to the immediate cgroup (if it has a parent, aka !root).

On update it does a DFS of all sub-groups and propagates the deltas up to the requested group.

...

Quoted 3 lines

What I don't get is why you need cgroup_cpu_stat_updated(). That is, I see you use it to keep the keep the DFS 'stack' up-to-date, but what I don't see is why you'd need that.

That is to make reading stats O(number of descendants which have been active since last read) instad of O(number of all descendants) as there can be a lot of not-too-active cgroups in a system. Stat reading can be frequent, so the combination can get really bad. By keeping the updated list separate, increasing read frequency decreases the cost of each read.

Also, please note that a system may end up with a lot of cgroups without the user intending to. memcg drains removed cgroups lazily and the number of draining cgroups can reach very high numbers if the system isn't under memory pressure. The plan is to add basic stats for other resources too and keeping it scalable w.r.t. idle cgroups allows using the same mechanism for all resources.

Quoted 6 lines

Also, please note that a system may end up with a lot of cgroups without the user intending to. memcg drains removed cgroups lazily and the number of draining cgroups can reach very high numbers if the system isn't under memory pressure. The plan is to add basic stats for other resources too and keeping it scalable w.r.t. idle cgroups allows using the same mechanism for all resources.

I think it will be good to put the rationale behind this function as a comment in the code.

Hello, Peter.

Quoted 5 lines · Peter Zijlstra

So I mostly like. On accounting it only adds to the immediate cgroup (if it has a parent, aka !root).

On update it does a DFS of all sub-groups and propagates the deltas up to the requested group.

...

Quoted 3 lines

What I don't get is why you need cgroup_cpu_stat_updated(). That is, I see you use it to keep the keep the DFS 'stack' up-to-date, but what I don't see is why you'd need that.

That is to make reading stats O(number of descendants which have been active since last read) instad of O(number of all descendants) as there can be a lot of not-too-active cgroups in a system. Stat reading can be frequent, so the combination can get really bad. By keeping the updated list separate, increasing read frequency decreases the cost of each read.

In cgroup1, while cpuacct isn't actually controlling any resources, it is a separate controller due to combination of two factors -
1. enabling cpu controller has significant side effects, and 2. we have to pick one of the hierarchies to account CPU usages on. cpuacct controller is effectively used to designate a hierarchy to track CPU usages on.

cgroup2's unified hierarchy removes the second reason and we can account basic CPU usages by default. While we can use cpuacct for this purpose, both its interface and implementation leave a lot to be desired - it collects and exposes two sources of truth which don't agree with each other and some of the exposed statistics don't make much sense. Also, it propagates all the way up the hierarchy on each accounting event which is unnecessary.

This patch adds basic resource accounting mechanism to cgroup2's unified hierarchy and accounts CPU usages using it.

* All accountings are done per-cpu and don't propagate immediately. It just bumps the per-cgroup per-cpu counters and links to the parent's updated list if not already on it.

* On a read, the per-cpu counters are collected into the global ones and then propagated upwards. Only the per-cpu counters which have changed since the last read are propagated.

* CPU usage stats are collected and shown in "cgroup.stat" with "cpu." prefix. Total usage is collected from scheduling events. User/sys breakdown is sourced from tick sampling and adjusted to the usage using cputime_adjust().

This keeps the accounting side hot path O(1) and per-cpu and the read side O(nr_updated_since_last_read).

v2: Minor changes and documentation updates as suggested by Waiman and
Roman.

Signed-off-by Tejun Heo <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Li Zefan <[email protected]>

Cc Johannes Weiner <[email protected]>

Cc Waiman Long <[email protected]>

Quoted 1 line

Cc Waiman Long <[email protected]>

I just noticed that you have used my obsoleted email address in the cc line. Would you mind changing it to the one that I am currently using?

This patchset implement cgroup2 basic resource accounting and track CPU usages on all cgroups by default.

Hello,

Quoted 2 lines · Tejun Heo

This patchset implement cgroup2 basic resource accounting and track CPU usages on all cgroups by default.

Ping. I've renamed as Waiman suggested. If there's no further objection, how should we route these patches and the following cpu cgroup2 interface patch?

Please hold off on applying it before PeterZ gets back from vacation and has had a chance to review it.

Hello, Ingo.

Quoted 2 lines · Ingo Molnar

Please hold off on applying it before PeterZ gets back from vacation and has had a chance to review it.

Of course. These aren't going anywhere without Peter's explicit acks.

Peter, ping?

Quoted 1 line · Tejun Heo

Peter, ping?

Humm,. So I think I was good, but I was under the impression you'd send a new version better explaining the need/design of that iteration stuff. Could be I lost the plot somehow.

Hello, Peter.

Quoted 3 lines · Peter Zijlstra

Quoted 1 line · Tejun Heo

Peter, ping?

Quoted 3 lines

Humm,. So I think I was good, but I was under the impression you'd send a new version better explaining the need/design of that iteration stuff. Could be I lost the plot somehow.

The updated version was posted quite a while ago.

http://lkml.kernel.org/r/20170829174325.GS491396-4dN5La/[email protected]

Quoted 10 lines · Tejun Heo

Hello, Peter.

Quoted 6 lines · Peter Zijlstra

Quoted 1 line · Tejun Heo

Peter, ping?

Humm,. So I think I was good, but I was under the impression you'd send a new version better explaining the need/design of that iteration stuff. Could be I lost the plot somehow.

Quoted 3 lines

The updated version was posted quite a while ago.

http://lkml.kernel.org/r/20170829174325.GS491396-4dN5La/[email protected]

Oh that's in the same thread, wasn't expecting that. Look ok I suppose.

Acked-by Peter Zijlstra (Intel) <[email protected]>

Hello,

Another follow-up fix. I missed a dummy implementation leading to bulid failure on s390. Because the bug and fix are trivial, I directly applied the patch to cgroup/for-4.15. Please let me know if it should be routed differently.

Thanks.
------ 8< ------
From 8157a7faf94135386bf04b1cf94e6efd3fb94702 Mon Sep 17 00:00:00 2001
From: Tejun Heo <[email protected]>
Date: Mon, 25 Sep 2017 14:27:54 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cfb766da54d9 ("sched/cputime: Expose cputime_adjust()") made cputime_adjust() public for cgroup basic cpu stat support; however, the commit forgot to add a dummy implementaiton for CONFIG_VIRT_CPU_ACCOUNTING_NATIVE leading to compiler errors on some s390 configurations.

Fix it by adding the missing dummy implementation.

Reported-by “[email protected]” <[email protected]>

Fixes cfb766da54d9 ("sched/cputime: Expose cputime_adjust()")

Signed-off-by Tejun Heo <[email protected]>