On Tue, Apr 4, 2023 at 9:53 AM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > On Thu, Mar 30, 2023 at 07:17:59PM +0000, Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > In workingset_refault(), we call > > mem_cgroup_flush_stats_atomic_ratelimited() to read accurate stats > > within an RCU read section and with sleeping disallowed. Move the > > call above the RCU read section to make it non-atomic. > > > > Flushing is an expensive operation that scales with the number of cpus > > and the number of cgroups in the system, so avoid doing it atomically > > where possible. > > I understand why one does not process the whole flushing load in one go > in general. > However, I remember there were reports of workingset_refault() being > sensitive to latencies (hence the ratelimited call was created). > > Is there any consideration on impact of this here? > (Or are there other cond_resched() precendents on this path? Should it > be mentioned like in the vmscan (7/8) commit?) IIUC there are multiple places where we can sleep in this path, we can sleep waiting for a page to be read from disk, we can sleep during allocating the page to read into, and IIUC the allocations on the fault path can even run into reclaim, going into the vmscan code. So there are precedents, but I am not sure if that's enough argument. I did some light performance testing and I did not notice any regressions (i.e concurrent processes faulting memory with a lot of cgroups/cpus), but this change is done intentionally in a separate patch so that it's easy to revert if regressions are reported. > > Thanks, > Michal
