On Fri, Jul 10, 2026 at 10:30 AM Nhat Pham <[email protected]> wrote: > > On Wed, Jul 8, 2026 at 12:08 PM Yosry Ahmed <[email protected]> wrote: > > > > On Wed, Jul 8, 2026 at 12:00 PM Michal Koutný <[email protected]> wrote: > > > > > > On Tue, Jul 07, 2026 at 02:49:56PM -0700, Yosry Ahmed <[email protected]> > > > wrote: > > > > I would honestly rather use more memory. I think there might be cases > > > > where the flusher is delayed. The flush being slightly delayed is not > > > > technically a bug that we want to see a failure for, but if a large > > > > stats change is not visible that's a user-noticeable behavior that we > > > > want a failure for. > > > > > > > > WDYT? > > > > > > There's already the (recent) page size-based scaling, so the idea with > > > nr_cpus scaling could make the selftest useful on wider range of setups > > > (even page size can be considered as a slight implementation detail > > > leak, thus the justification of nr_cpus dependency). > > > > > > Also, I still think that internally the threshold should be changed to > > > the "harmonic" formula [1] but the selftest can go with the linear > > > dependency for more pronounced effects. > > > > Yeah I agree the threshold formula can be improved, but we need to > > make sure performance doesn't regress. > > Yeah that's a separate discussion indeed. For now I'm fine with fixing > the selftests by using more memory. > > Is there a good generic formula for this? I understand there will be > hardcode values, but at least making it scalable (by how much memory > we have, page size, # of cpus) if possible? :)
The rstat formula depends on the number of CPUs and a constant factor (see memcg_vmstats_needs_flush()), but this formula is for the number of updates (e.g. number of pages reclaimed), and that value will decrease as the page size increases. So I think we want to scale with both the page size and the number of CPUs. The amount of memory in the system is not a factor for now.
