> > Yes, this is true. cgroup_rstat_ops was only added to allow cgroup_bpf > > to make use of rstat. If the bpf flushing remains tied to > > cgroup_subsys_state::self, then the ops interface and supporting code > > can be removed. Probably stating the obvious but the trade-off would be > > that if bpf cgroups are in use, they would account for some extra > > overhead while flushing the base stats. Is Google making use of bpf- > > based cgroups? > > > > Ironically I don't know, but I don't expect the BPF flushing to be > expensive enough to affect this. If someone has the use case that loads > enough BPF programs to cause a noticeable impact, we can address it > then. > > This series will still be an improvement anyway. I actually just remembered. Using BPF programs to collect stats using rstat is currently independent of the CGROUP_BPF stuff. So I think this approach breaks that anyway.
