Hello, On Tue, May 10, 2022 at 01:43:46PM -0700, Yosry Ahmed wrote: > I assume if we do this optimization, and have separate updated lists > for controllers, we will still have a "core" updated list that is not > tied to any controller. Is this correct? Or we can create a dedicated updated list for the bpf progs, or even multiple for groups of them and so on. > If yes, then we can make the interface controller-agnostic (a global > list of BPF flushers). If we do the optimization later, we tie BPF > stats to the "core" updated list. We can even extend the userland > interface then to allow for controller-specific BPF stats if found > useful. We'll need that anyway as cpustats are tied to the cgroup themselves rather than the cpu controller. > If not, and there will only be controller-specific updated lists then, > then we might need to maintain a "core" updated list just for the sake > of BPF programs, which I don't think would be favorable. If needed, that's fine actually. > What do you think? Either-way, I will try to document our discussion > outcome in the commit message (and maybe the code), so that > if-and-when this optimization is made, we can come back to it. So, the main focus is keeping the userspace interface as simple as possible and solving performance issues on the rstat side. If we need however many updated lists to do that, that's all fine. FWIW, the experience up until now has been consistent with the assumptions that the current implementation makes and I haven't seen real any world cases where the shared updated list are problematic. Thanks. -- tejun
