linux-kernel - Re: [PATCH v2] mm/slub: Reduce memory consumption in extreme scenarios

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <906fcdfc-f2da-428d-af3d-e1eaf64d1c61@suse.cz>
Date: Tue, 2 Apr 2024 18:08:53 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Chen Jun <chenjun102@...wei.com>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
 iamjoonsoo.kim@....com, akpm@...ux-foundation.org, roman.gushchin@...ux.dev,
 42.hyeyoo@...il.com
Cc: xuqiang36@...wei.com, wangkefeng.wang@...wei.com
Subject: Re: [PATCH v2] mm/slub: Reduce memory consumption in extreme
 scenarios

On 3/30/24 9:23 AM, Chen Jun wrote:
> When kmalloc_node() is called without __GFP_THISNODE and the target node
> lacks sufficient memory, SLUB allocates a folio from a different node
> other than the requested node, instead of taking a partial slab from it.
> 
> However, since the allocated folio does not belong to the requested
> node, it is deactivated and added to the partial slab list of the node
> it belongs to.
> 
> This behavior can result in excessive memory usage when the requested
> node has insufficient memory, as SLUB will repeatedly allocate folios
> from other nodes without reusing the previously allocated ones.
> 
> To prevent memory wastage,
> when (node != NUMA_NO_NODE) && !(gfpflags & __GFP_THISNODE) is,
> 1) try to get a partial slab from target node with GFP_NOWAIT |
>    __GFP_THISNODE opportunistically.
> 2) if 1) failed, try to allocate a new slab from target node with
>    GFP_NOWAIT | __GFP_THISNODE opportunistically too.
> 3) if 2) failed, retry 1) and 2) with orignal gfpflags.
> 
> when node != NUMA_NO_NODE || (gfpflags & __GFP_THISNODE), the behavior
> remains unchanged.
> 
> On qemu with 4 numa nodes and each numa has 1G memory. Write a test ko
> to call kmalloc_node(196, GFP_KERNEL, 3) for (4 * 1024 + 4) * 1024 times.
> 
> cat /proc/slabinfo shows:
> kmalloc-256       4200530 13519712    256   32    2 : tunables..
> 
> after this patch,
> cat /proc/slabinfo shows:
> kmalloc-256       4200558 4200768    256   32    2 : tunables..
> 
> Signed-off-by: Chen Jun <chenjun102@...wei.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@...wei.com>

Slightly reworded and added an unlikely() to one of the tests, and included
in slab/for-6.10:

https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git/commit/?h=slab/for-6.10/cleanup&id=9198ffbd2b494daae3a67cac1d59c3a2754e64cd

Thanks!