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

["Vishal Moola (Oracle)" <vishal.moola@gmail.com>]

On Mon, Nov 17, 2025 at 11:16:51PM +0000, Preble, Adam C wrote:
> I had sent a note to the list a few weeks ago about a situation where my vmap_area allocations were continuing to grow and I couldn't account for anything in a kmemleak report (it was completely empty). This lead me (thanks, Lance!) to enabling CONFIG_MEM_ALLOC_PROFILING=y. I then saved /proc/allocinfo before and after my workloads. I then used a script to collect the two reports, determine what grew, and sort it by how each tagged allocation grew.

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

> I got a bunch of suspicious things, but I couldn't trace any of it back to anything I were doing. For example, I tried to collect kstacks with bpftrace by kprobing any of these functions I could. I mostly had to get near them because a lot didn't have direct trace points. I haven't tried with manually-inserted trace points yet.
> 
> After multiple experiments, I took it back to a stock kernel (6.17, tag v6.17 commit e5f0a698b34ed76002dc5cff3804a61c80233a7a) and just let it sit idle for a few days. This still generated some growth:
> 
>     Growth    NewSize TagInfo
> ============================================================
>  676085760  820760576 mm/slub.c:2492 func:alloc_slab_page
>  591151104  672784384 mm/filemap.c:1981 func:__filemap_get_folio
>  528635360  532319824 fs/ext4/super.c:1384 func:ext4_alloc_inode
>  187793408  325976064 mm/readahead.c:186 func:ractl_alloc_folio
>   95700288  103415040 fs/dcache.c:1690 func:__d_alloc
>   29970432   63787008 mm/slub.c:2494 func:alloc_slab_page
>   20316160   39485440 mm/percpu-vm.c:95 func:pcpu_alloc_pages
>   15044120   16415048 fs/buffer.c:3025 func:alloc_buffer_head
>    3116224    8994768 lib/xarray.c:378 func:xas_alloc
>    2138208    4317472 mm/percpu.c:512 func:pcpu_mem_zalloc
> 
> I don't entirely know what I'm looking at with all this yet; kernel memory management beyond kmalloc and vmalloc wasn't really on my 2025 bingo card. I only listened to a talk about folios after I first saw this stuff and didn't know they were a thing before now. There are a few things I can still do to try to normalize my setup like taking it to a stock Linux image of some kind in QEMU, but I was hoping for some advice before I keep slashing away. If there's one quirky thing to disclose, it's that the file system is ext3.

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.

> First, is any of that information actually relevant? Like, I wonder if I'm just looking at some records that are known to not have their corresponding free operations properly correlated. Second, would any of that actually be relevant to progressive growth of vmap_area?

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.

[1] https://lore.kernel.org/linux-mm/PH7PR11MB6523C5200943207E879FB5CAA9F8A@PH7PR11MB6523.namprd11.prod.outlook.com/