On Tue, May 10, 2022 at 2:01 PM Tejun Heo <tj@xxxxxxxxxx> wrote: > > 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 again for your insights and time! That's great to hear. I am all in for making the userspace interface simpler. I will rework this patch series so that the BPF programs just attach to "rstat" and send a V1. Any other concerns you have that you think I should address in V1? > Thanks. > > -- > tejun
