Received-SPF: pass (google.com: domain of linux-kernel+bounces-128323-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <906fcdfc-f2da-428d-af3d-e1eaf64d1c61@suse.cz>
Date: Tue, 2 Apr 2024 18:08:53 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] mm/slub: Reduce memory consumption in extreme
 scenarios
Content-Language: en-US
To: Chen Jun <chenjun102@huawei.com>, linux-kernel@vger.kernel.org,
 linux-mm@kvack.org, cl@linux.com, penberg@kernel.org, rientjes@google.com,
 iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev,
 42.hyeyoo@gmail.com
Cc: xuqiang36@huawei.com, wangkefeng.wang@huawei.com
References: <20240330082335.29710-1-chenjun102@huawei.com>
From: Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <20240330082335.29710-1-chenjun102@huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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@huawei.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.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!