On Tue, Jun 25, 2024 at 09:00:03AM GMT, Yosry Ahmed wrote: [...] > > My point is not about accuracy, although I think it's a reasonable > argument on its own (a lot of things could change in a short amount of > time, which is why I prefer magnitude-based ratelimiting). > > My point is about logical ordering. If a userspace program reads the > stats *after* an event occurs, it expects to get a snapshot of the > system state after that event. Two examples are: > > - A proactive reclaimer reading the stats after a reclaim attempt to > check if it needs to reclaim more memory or fallback. > - A userspace OOM killer reading the stats after a usage spike to > decide which workload to kill. > > I listed such examples with more detail in [1], when I removed > stats_flush_ongoing from the memcg code. > > [1]https://lore.kernel.org/lkml/20231129032154.3710765-6-yosryahmed@xxxxxxxxxx/ You are kind of arbitrarily adding restrictions and rules here. Why not follow the rules of a well established and battle tested stats infra used by everyone i.e. vmstats? There is no sync flush and there are frequent async flushes. I think that is what Jesper wants as well. Shakeel
