Hi Tejun,

On Wed, Jan 12, 2022 at 12:24 PM Tejun Heo [off-list ref] wrote:

Hello,

On Tue, Jan 11, 2022 at 03:38:20PM -0800, Josh Don wrote:

quoted

Is the concern there just the extra overhead from making multiple
trips into this handler and re-allocating the buffer until it is large
enough to take all the output? In that case, we could pre-allocate
with a size of the right order of magnitude, similar to /proc/stat.

Lack of per-cpu stats is a gap between cgroup v1 and v2, for which v2
can easily support this interface given that it already tracks the
stats percpu internally. I opted to dump them all in a single file
here, to match the consolidation that occurred from cpuacct->cpu.stat.

Yeah, nack on this. That part was dropped intentionally. These text pseudo
files aren't a great medium for this sort of (potentially large) data dump
and they scale really badly with new fields which we may want to expose in
the future. For detailed introspection, a better route would be using bpf
and if that's inconvenient for some reason trying to make them more
convenient.

Fair enough. Apart from needing to expose an rstat flush mechanism to
BPF, the main issues that come to mind are conveniently associating
with a particular cgroup, and allowing non-root to collect stats
independently. Hao's patch series
(https://lkml.kernel.org/r/%3C20220112192547.3054575-1-haoluo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org%3E)
makes this particularly convenient, but that's a topic for a separate
conversation :)