Re: [PATCH V2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

[Shakeel Butt <shakeel.butt@linux.dev>]

On Mon, Jun 24, 2024 at 10:40:48AM GMT, Yosry Ahmed wrote:
> On Mon, Jun 24, 2024 at 10:32 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> >
> > On Mon, Jun 24, 2024 at 05:46:05AM GMT, Yosry Ahmed wrote:
> > > On Mon, Jun 24, 2024 at 4:55 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
> > >
> > [...]
> > > I am assuming this supersedes your other patch titled "[PATCH RFC]
> > > cgroup/rstat: avoid thundering herd problem on root cgrp", so I will
> > > only respond here.
> > >
> > > I have two comments:
> > > - There is no reason why this should be limited to the root cgroup. We
> > > can keep track of the cgroup being flushed, and use
> > > cgroup_is_descendant() to find out if the cgroup we want to flush is a
> > > descendant of it. We can use a pointer and cmpxchg primitives instead
> > > of the atomic here IIUC.
> > >
> > > - More importantly, I am not a fan of skipping the flush if there is
> > > an ongoing one. For all we know, the ongoing flush could have just
> > > started and the stats have not been flushed yet. This is another
> > > example of non deterministic behavior that could be difficult to
> > > debug.
> >
> > Even with the flush, there will almost always per-cpu updates which will
> > be missed. This can not be fixed unless we block the stats updaters as
> > well (which is not going to happen). So, we are already ok with this
> > level of non-determinism. Why skipping flushing would be worse? One may
> > argue 'time window is smaller' but this still does not cap the amount of
> > updates. So, unless there is concrete data that this skipping flushing
> > is detrimental to the users of stats, I don't see an issue in the
> > presense of periodic flusher.
> 
> As you mentioned, the updates that happen during the flush are
> unavoidable anyway, and the window is small. On the other hand, we
> should be able to maintain the current behavior that at least all the
> stat updates that happened *before* the call to cgroup_rstat_flush()
> are flushed after the call.
> 
> The main concern here is that the stats read *after* an event occurs
> should reflect the system state at that time. For example, a proactive
> reclaimer reading the stats after writing to memory.reclaim should
> observe the system state after the reclaim operation happened.

What about the in-kernel users like kswapd? I don't see any before or
after events for the in-kernel users.

> 
> Please see [1] for more details about why this is important, which was
> the rationale for removing stats_flush_ongoing in the first place.
> 
> [1]https://lore.kernel.org/lkml/20231129032154.3710765-6-yosryahmed@google.com/
>