> On Feb 24, 2022, at 5:17 AM, Vasily Averin <vvs@xxxxxxxxxxxxx> wrote: > > On 22.02.2022 19:32, Shakeel Butt wrote: >> If you are just interested in the stats, you can use SLAB for your experiments. > > Unfortunately memcg_slabino.py does not support SLAB right now. > >> On 23.02.2022 20:31, Vlastimil Babka 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. > > I like this idea too and I'm going to spend some time for its implementation. Sounds good! Unfortunately it’s quite tricky: the problem is that there is potentially a large and dynamic set of cgroups and also large and dynamic set of slab caches. Given the performance considerations, it’s also unlikely to avoid using percpu variables. So we come to the (nr_slab_caches * nr_cgroups * nr_cpus) number of “objects”. If we create them proactively, we’re likely wasting lot of memory. Creating them on demand is tricky too (especially without losing some accounting accuracy). Thanks!
