Memory leak in 6.18

Vlastimil Babka vbabka at suse.cz
Mon Nov 10 08:47:13 PST 2025


On 11/10/25 07:16, Harry Yoo wrote:
> On Mon, Nov 10, 2025 at 03:04:02PM +0900, Harry Yoo wrote:
>> On Sun, Nov 09, 2025 at 11:36:26PM +0100, Tytus Rogalewski wrote:
>> > Hi guys,
>> > 
>> > Been using 6.18 kernel and i have noticed that there is some memory leak.
>> > Currently mapple_node takes 86GB when server does not do much.
>> > I do not see that issue on 6.17 kernel at all.
> 
> Cc'ing linux-mm at kvack.org properly as I modified the address by mistake.
> 
>> Hi Tytus, thanks for the report!
>> 
>> Could you please boot your machine with kernel boot
>> parameter slab_debug=U [1] and run
>> 
>> $ cat /sys/kernel/debug/slab/maple_node/alloc_traces
>> 
>> and
>> 
>> $ cat /sys/kernel/debug/slab/maple_node/free_traces

Agreed. What could help in addition to above is also enabling
CONFIG_SLUB_STATS and also providing the output of:

grep . /sys/kernel/slab/maple_node/*

Thanks.

>> ?
>> > Total 1000 GB memory
>> > ASRockRack GENOA2D24G-2L
>> > 2x AMD EPYC 9654 96-Core Processor
>> > Running Proxmox 9
>> > 
>> >  Active / Total Objects (% used)    : 472110239 / 472257124 (100.0%)
>> >  Active / Total Slabs (% used)      : 7385489 / 7385489 (100.0%)
>> >  Active / Total Caches (% used)     : 164 / 231 (71.0%)
>> >  Active / Total Size (% used)       : 95486861.00K / 95528053.72K (100.0%)
>> >  Minimum / Average / Maximum Object : 0.01K / 0.20K / 8.06K
>> > 
>> >   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
>> > 345907216 345897683  99%    0.25K 5404801       64  86476816K maple_node
>> > 120873408 120841337  99%    0.06K 1888647       64   7554588K dmaengine-unmap-2
>> > 224256 223324  99%    0.01K    438      512      1752K kmalloc-8
>> > 224040 224040 100%    0.13K   3734       60     29872K kernfs_node_cache
>> > 196608 196608 100%    0.01K    384      512      1536K kmalloc-cg-8
>> > 196160 166455  84%    0.50K   3065       64     98080K kmalloc-512
>> 
>> Not sure if this is because of sheaves or maple tree changes.
>> Let's see what's in the alloc & free traces.
>> 
>> Or it would be great if you could build the kernel and perform
>> git bisection [2] and give us what is the first bad commit.
>> 
>> Thanks!
>> 
>> [1] https://docs.kernel.org/next/admin-guide/mm/slab.html 
>> [2] https://git-scm.com/docs/git-bisect
> 




More information about the maple-tree mailing list