On Tue, Aug 29, 2023 at 11:44 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > Hello, > > On Fri, Aug 25, 2023 at 09:05:46AM +0200, Michal Hocko wrote: > > > > I think that's how it was always meant to be when it was designed. The > > > > global rstat lock has always existed and was always available to > > > > userspace readers. The memory controller took a different path at some > > > > point with unified flushing, but that was mainly because of high > > > > concurrency from in-kernel flushers, not because userspace readers > > > > caused a problem. Outside of memcg, the core cgroup code has always > > > > exercised this global lock when reading cpu.stat since rstat's > > > > introduction. I assume there hasn't been any problems since it's still > > > > there. > > > > I suspect nobody has just considered a malfunctioning or adversary > > workloads so far. > > > > > > I was hoping Tejun would confirm/deny this. > > > > Yes, that would be interesting to hear. > > So, the assumptions in the original design were: > > * Writers are high freq but readers are lower freq and can block. > > * The global lock is mutex. > > * Back-to-back reads won't have too much to do because it only has to flush > what's been accumulated since the last flush which took place just before. > > It's likely that the userspace side is gonna be just fine if we restore the > global lock to be a mutex and let them be. Most of the problems are caused > by trying to allow flushing from non-sleepable and kernel contexts. So basically restore the flush without disabling preemption, and if a userspace reader gets preempted while holding the mutex it's probably okay because we won't have high concurrency among userspace readers? I think Shakeel was worried that this may cause a priority inversion where a low priority task is preempted while holding the mutex, and prevents high priority tasks from acquiring it to read the stats and take actions (e.g. userspace OOMs). > Would it > make sense to distinguish what can and can't wait and make the latter group > always use cached value? e.g. even in kernel, during oom kill, waiting > doesn't really matter and it can just wait to obtain the up-to-date numbers. The problem with waiting for in-kernel flushers is that high concurrency leads to terrible serialization. Running a stress test with 100s of reclaimers where everyone waits shows ~ 3x slowdowns. This patch series is indeed trying to formalize a distinction between waiters who can wait and those who can't on the memcg side: - Unified flushers always flush the entire tree and only flush if no one else is flushing (no waiting), otherwise they use cached data and hope the concurrent flushing helps. This is what we currently do for most memcg contexts. This patch series opts userspace reads out of it. - Non-unified flushers only flush the subtree they care about and they wait if there are other flushers. This is what we currently do for some zswap accounting code. This patch series opts userspace readers into this. The problem Michal is raising is that dropping the lock can lead to an unbounded number of waiters and longer worst case latency. Especially that this is directly influenced by userspace. Reintroducing the mutex and removing the lock dropping code fixes that problem, but then if the mutex holder gets preempted, we face another problem. Personally I think there is a good chance there won't be userspace latency problems due to the lock as usually there isn't high concurrency among userspace readers, and we can deal with that problem if/when it happens. So far no problem is happening for cpu.stat which has the same potential problem.
