On Wed, Aug 14, 2024 at 5:19 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > On Wed, Aug 14, 2024 at 4:49 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > We can also use such atomic counters in obj_cgroup_may_zswap() and > > eliminate the rstat flush there as well. Same for zswap_current_read() > > probably. > > zswap/zswapped are subtree-cumulative counters. Would that be a problem? For obj_cgroup_may_zswap() we iterate the parents anyway, so I think it should be fine. We will also iterate the nodes on each level, but this is usually a small number and is probably cheaper than an rstat flush (but I can easily be wrong). For zswap_current_read() we need to iterate the children, not the parents. At this point the rstat flush is probably much better, so we can leave this one alone. It's a userspace read anyway, so it shouldn't be causing problems. > > > > > Most in-kernel flushers really only need a few stats, so I am > > wondering if it's better to incrementally move these ones outside of > > the rstat framework and completely eliminate in-kernel flushers. For > > instance, MGLRU does not require the flush that reclaim does as > > Shakeel pointed out. > > > > This will solve so many scalability problems that all of us have > > observed at some point or another and tried to optimize. I believe > > using rstat for userspace reads was the original intention anyway. > > But yeah, the fewer in-kernel flushers we have, the fewer > scalability/lock contention issues there will be. Not an expert in > this area, but sounds like a worthwhile direction to pursue.
