On Fri, Mar 18, 2022 at 12:59 PM Song Liu <song@xxxxxxxxxx> wrote: > > On Wed, Mar 9, 2022 at 12:27 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > Hey everyone, > > > > I would like to discuss an idea to facilitate collection of > > hierarchical cgroup stats using BPF programs. We want to provide a > > simple interface for BPF programs to collect hierarchical cgroup stats > > and integrate with the existing rstat aggregation mechanism in the > > kernel. The most prominent use case is the ability to extend memcg > > stats (and histograms) by BPF programs. > > > > + Namhyung, > > I forgot to mention this in the office hour. The aggregation efficiency > problem is actually similar to Namhyung's work to use BPF programs > to aggregate perf counters. Check: > tools/perf/util/bpf_skel/bperf_cgroup.bpf.c > > Namhyung's solution is to walk up the cgroup tree on cgroup switch > events. This may not be as efficient as rstat flush logic, but I think it > is good enough for many use cases (unless the cgroup tree is very > deep). It also demonstrates how we can implement some cgroup > logic in BPF. > > I hope this helps. > > Thanks, > Song > > [...] Hi Song, Thanks so much for pointing this out. I have an idea of a less intrusive and more generic way to directly use rstat flushing in BPF programs, which basically makes BPF programs maintain their own stats and flushing logic and only using helpers to make calls to rstat (instead of a whole new rstat map). I will work on an RFC patch series for this. If this doesn't work out, I will probably fallback to handling the flushing completely in the BPF programs, similar to the example you provided (which is a lot of help, thanks!).
