Re: slabinfo shows incorrect active_objs ???

[Hyeonggon Yoo <42.hyeyoo@gmail.com>]

On Wed, Feb 23, 2022 at 01:32:36AM +0100, Vlastimil Babka wrote:
> On 2/23/22 01:07, Roman Gushchin wrote:
> > 
> >> On Feb 22, 2022, at 3:08 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
> >> 
> >> On 2/22/22 21:59, Roman Gushchin wrote:
> >>> 
> >>>> On Feb 22, 2022, at 4:10 AM, Vasily Averin <vvs@virtuozzo.com> wrote:
> >> 
> >> BTW please To/Cc directly all slab maintainers on future slab related
> >> threads (added now).
> >> 
> >>>> On 22.02.2022 13:23, Hyeonggon Yoo wrote:
> >>>>>>> On Tue, Feb 22, 2022 at 12:22:02PM +0300, Vasily Averin wrote:
> >>>>>>> Dear all,
> >>>>>>> 
> >>>>>>> I've found that /proc/slabinfo shows inadequate numbers of in-use slab objects.
> >>>>>>> it assumes that all objects stored in cpu caches are always 100% in use.
> >>>> 
> >>>>>> Is it a bug or perhaps a well-known feature that I missed?
> >>>>> This is not a bug..
> >>>> 
> >>>> Thank you for explanation,
> >>>> I think it would be useful to document this somewhere. (Documnetation? man slabinfo ?)
> >>>> Also I would like to know is it some (fast) way to get real numbers in userspace ?
> >>>> crash is too fat for this task.
> >>>> Do you know perhaps some other userspace utility or may be systemtap/drgn script?
> >>> 
> >>> Btw, implementing fast slab counters independent from the sl*b implementation and the physical layout of data might be an interesting idea.
> >> 
> >> Interesting idea, but merging will be an issue if we ever manage to
> >> officially allow kfree() on object allocated by kmem_cache_alloc() - which
> >> is now blocked by SLOB (there was a recent thread that stalled).
> > 
> > Well, we can store an id somewhere (like right behind the object).
> > Depending on the object size and padding it might even take not so much
> > extra space. Maybe not the feature everybody needs (so it can be turned
> > off by default), but something that can be really useful in some cases.

> 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()...

Or would you count them by iterating all of cpu partial slabs and node
partial slabs? (Something like drgn script or new procfs file?)

-- 
Hyeonggon