On Thu, Nov 4, 2021 at 2:27 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 14 Oct 2021 09:31:46 -0700 Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > > Hi Michal, > > > > On Wed, Oct 13, 2021 at 11:01 AM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > > > > > On Fri, Oct 01, 2021 at 12:00:39PM -0700, Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > > > In this patch we kept the stats update codepath very minimal and let the > > > > stats reader side to flush the stats only when the updates are over a > > > > specific threshold. For now the threshold is (nr_cpus * CHARGE_BATCH). > > > > > > BTW, a noob question -- are the updates always single page sized? > > > > > > This is motivated by apples vs oranges comparison since the > > > nr_cpus * MEMCG_CHARGE_BATCH > > > suggests what could the expected error be in pages (bytes). But it's mostly > > > wrong since: a) uncertain single-page updates, b) various counter > > > updates summed together. I wonder whether the formula can serve to > > > provide at least some (upper) estimate. > > > > > > > Thanks for your review. This forces me to think more on this because each > > update does not necessarily be a single page sized update e.g. adding a hugepage > > to an LRU. > > > > Though I think the error is time bounded by 2 seconds but in those 2 seconds > > mathematically the error can be large. > > Sounds significant? Yes it can be. > > > What do you think of the following > > change? It will bound the error better within the 2 seconds window. > > This didn't seem to go anywhere. I'll send "memcg: flush stats only if > updated" Linuswards, but please remember to resurrect this idea soonish > (this month?) if you think such a change is desirable. > Yes, I will follow up on this soon.
