Re: Understanding profiled tagged allocator growth in a stock kernel that's just idling

["Preble, Adam C" <adam.c.preble@intel.com>]

On Tue, 2025-11-18 at 10:24 -0800, Vishal Moola (Oracle) wrote:
> When making referencees, please link them. Especially in cases like
> this
> where the subject line is different from your first post[1]. It makes
> it
> easier to keep track of discussions :).
> 

Fair enough! My last bit about it is here [1]. I also got a better e-
mail client setup going (hopefully).

> 
> 
> The numbers here look pretty normal to me. There are a number of
> places
> where we can reuse objects, so we don't proactively free them.

Okay, I am going to assume I'm just looking at non sequiturs there.

> I'd recommend confirming that the external module isn't the source of
> the leak first. Memory allocation profiling doesn't track statistics
> once a module is unloaded, so I'd recommend inserting a 'while(1);'
> in
> the last line of your module, then checking /proc/allocinfo.
> 
> Also, afaik vmap_area is only allocated from within mm/vmalloc.c, so
> if
> this is a kernel-side leak, I'd start looking from there first.

I threw in an infinite loop right at the end and ... initially didn't
hit it. It looks like deinitialization was blocked on something and
didn't continue until I echo'd 3 to /proc/sys/vm/drop_caches. I only
got to the end after that. This is alarming for my own code, and I will
be looking into it too. However, my normal test payload with the
growing vmap_area drops the caches, so I've been getting my
measurements with deinitialization terminating.

Here's the top 20 when I look at what I captured after having all the
caches dropped:

    Growth    NewSize TagInfo
============================================================
   7176192   11071488 mm/shmem.c:1908 func:shmem_alloc_folio
    983040   19496960 mm/percpu-vm.c:95 func:pcpu_alloc_pages
    860160    1122304 arch/x86/mm/pat/set_memory.c:1239
func:split_large_page
    806912   33808384 mm/slub.c:2496 func:alloc_slab_page
    552960     806912 mm/memory.c:468 func:__pte_alloc_kernel
    164160    8224416 kernel/fork.c:311 func:alloc_thread_stack_node
     61440    1507328 kernel/dma/direct.c:142
func:__dma_direct_alloc_pages
     20480    1372160 arch/x86/mm/pgtable.c:18 func:pte_alloc_one
     12288      45056 lib/alloc_tag.c:430 func:vm_module_tags_populate
      8760     821104 lib/radix-tree.c:253 func:radix_tree_node_alloc
      8192     264704 mm/list_lru.c:410 func:memcg_init_list_lru_one
      6528      95904 mm/vmalloc.c:3176 func:__get_vm_area_node
      5760       9024 net/core/dst.c:89 func:dst_alloc
      4096     221184 arch/x86/mm/pgtable.c:314 func:_pgd_alloc
      4096       7168 drivers/tty/tty_buffer.c:180
func:tty_buffer_alloc
      3680    2297056 mm/shmem.c:5211 func:shmem_alloc_inode
      3328       3840 net/core/skbuff.c:283 func:napi_skb_cache_get
      2944      17664 kernel/fork.c:1487 func:dup_mm
      2560       2560 ipc/sem.c:517 func:sem_alloc
      2016       2800 fs/ext4/mballoc.c:5695 func:ext4_mb_pa_alloc

If vmap_area is my perpetually-growing slab allocator, then I suppose I
should look at __get_vm_area_node. It has an alloc_vmap_area call. If I
have to, I'd just make my own trace point so I could collect kstacks
from it. I assume I would store the pointers acquired from the
alloc_vmap_area call within __get_vm_area_node and then also attach to
free_vmap_area to test when they are reclaimed.

Also, thanks for the idea of just looping at the end of the deinit. I
wouldn't normally have the mind to do something do that kind of evil
despite dropping int $3's all over the place.

https://lore.kernel.org/linux-mm/PH7PR11MB65239FC7763E954D4AA828A5A9CDA@PH7PR11MB6523.namprd11.prod.outlook.com/