On Mon, Feb 28, 2022 at 10:46 AM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > On Fri, Feb 25, 2022 at 05:42:57PM -0800, Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > Yes, the right fix would be to optimize the flushing code (but that > > would require more work/time). However I still think letting > > performance critical code paths to skip the sync flush would be good > > in general. So, if the current patch is not to your liking we can > > remove mem_cgroup_flush_stats() from workingset_refault(). > > What about flushing just the subtree of the memcg where the refault > happens? > It doesn't reduce the overall work and there's still full-tree > cgroup_rstat_lock but it should make the chunks of work smaller > durations more regular. > We can try that and I will send a patch to Ivan and Daniel to try on their workload to see the real impact of targeted memcg flushing. However I am not very optimistic about it.
