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@xxxxxxx> wrote: > >> > >> On 2/22/22 21:59, Roman Gushchin wrote: > >>> > >>>> On Feb 22, 2022, at 4:10 AM, Vasily Averin <vvs@xxxxxxxxxxxxx> 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
