> On Feb 23, 2022, at 9:31 AM, Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 2/23/22 04:45, Hyeonggon Yoo wrote: >>> On Wed, Feb 23, 2022 at 01:32:36AM +0100, Vlastimil Babka wrote: >>> Hm it would be easier just to disable merging when the precise counters are >>> enabled. Assume it would be a config option (possibly boot-time option with >>> static keys) anyway so those who don't need them can avoid the overhead. >> >> Is it possible to accurately account objects in SLUB? I think it's not >> easy because a CPU can free objects to remote cpu's partial slabs using >> cmpxchg_double()... > > AFAIU Roman's idea would be that each alloc/free would simply inc/dec an > object counter that's disconnected from physical handling of particular sl*b > implementation. It would provide exact count of objects from the perspective > of slab users. > I assume for reduced overhead the counters would be implemented in a percpu > fashion as e.g. vmstats. Slabinfo gathering would thus have to e.g. sum up > those percpu counters. Right, something like this. A bigger picture here: since we’ve moved to a per-object accounting, accounted allocations became a bit slower. It seems to be a non-issue in the real life (at least I haven’t seen any reports, maybe because it counter-weighted by memory savings and lower fragmentation), however benchmarks clearly show it and it’s something nice to fix at some point. The obvious solution is to maintain some sort of a per-memcg cache of pre-charged objects for particularly hot slab caches. But to do this we need to understand dynamically which slab caches are hot (and which cgroups are using them). This will require a per-memcg per-slab accounting mechanism. So maybe it will replace the drgn script in the long run. Thanks!
