On 2/20/25 9:59 AM, Yosry Ahmed wrote:
On Thu, Feb 20, 2025 at 09:53:33AM -0800, Shakeel Butt wrote:
On Thu, Feb 20, 2025 at 05:26:04PM +0000, Yosry Ahmed wrote:
Another question is, does it make sense to keep BPF flushing in the
"self" css with base stats flushing for now? IIUC BPF flushing is not
very popular now anyway, and doing so will remove the need to support
flushing and updating things that are not css's. Just food for thought.
Oh if this simplifies the code, I would say go for it.
I think we wouldn't need cgroup_rstat_ops and some of the refactoring
may not be needed. It will also reduce the memory overhead, and keep it
constant regardless of using BPF which is nice.
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?
