From patchwork Tue Apr 2 03:10:25 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Yang X-Patchwork-Id: 13613299 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E490CD1288 for ; Tue, 2 Apr 2024 03:11:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 813FD6B0085; Mon, 1 Apr 2024 23:11:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C35D6B0088; Mon, 1 Apr 2024 23:11:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B1FB6B0089; Mon, 1 Apr 2024 23:11:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4D77F6B0085 for ; Mon, 1 Apr 2024 23:11:11 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E06C31A08CF for ; Tue, 2 Apr 2024 03:11:10 +0000 (UTC) X-FDA: 81963115500.21.6CB3BC4 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf03.hostedemail.com (Postfix) with ESMTP id 945DB20016 for ; Tue, 2 Apr 2024 03:11:07 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of yangming73@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=yangming73@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712027469; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=lpXo2jTY1tiZU8QQ9rlA8dJIOrOacg3ePhj8d70Z0vk=; b=HfCZTJ5yvqEkcGmKHEZU7n0VvaGI0jpNuS+2bz9g1yKsRZbZZbMQU/cPVtovY4HHiQCXQ5 d3rl8Fgh8U6U0enVix5T/1UeZvZF3au19Rb8LMEwYaW3S10WvwOrHTestt+N9vvbEwuirQ 3hlH/lQIuyzql2GcQRdGrGeLvCfJE+c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712027469; a=rsa-sha256; cv=none; b=tInZ/zhkfkFEvkPWX05w0Bz6fs81mWwc8vlNRaNxEZU3zfGW6iBbioGONUl/AIVXK2rAfa LQuwrsOUz8q2oWaz80laZWoB5LvYSVKgnSecFhkcqWO08quOLnB+SgX83UVqBm96FH+fBP jMFOoU3bcEbaa1QevNg1vSIMtT7fkVo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of yangming73@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=yangming73@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4V7tB63fh6ztR23; Tue, 2 Apr 2024 11:08:30 +0800 (CST) Received: from dggpemd100003.china.huawei.com (unknown [7.185.36.199]) by mail.maildlp.com (Postfix) with ESMTPS id 299CE1404F6; Tue, 2 Apr 2024 11:11:03 +0800 (CST) Received: from huawei.com (10.174.184.140) by dggpemd100003.china.huawei.com (7.185.36.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Tue, 2 Apr 2024 11:11:02 +0800 From: Ming Yang To: , , , , , , , <42.hyeyoo@gmail.com>, , CC: , , , , , , Subject: [PATCH] slub: fix slub segmentation Date: Tue, 2 Apr 2024 11:10:25 +0800 Message-ID: <20240402031025.1097-1-yangming73@huawei.com> X-Mailer: git-send-email 2.32.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.174.184.140] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemd100003.china.huawei.com (7.185.36.199) X-Stat-Signature: 3otfo99cggu9iu19ro3qstwxdi96dgma X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 945DB20016 X-Rspam-User: X-HE-Tag: 1712027467-139664 X-HE-Meta: U2FsdGVkX1/cndIYwNLwIbShalFZCK5thHz8elaD2PSWbf6eqtQ6QM3idBiY3aY4+mogvF7hyyUUddaMgHZNW6Sbr3xNq3nHNdZ5TNPVM+J0po6/6imuM+IBoSUh1mRTChdGuP8Ne9ZtwwuNZPTPVEjT28hbsA9+3kRn7A5vtW9TJLEJyesLS67nT+kfwwcy4HPX2c4zfnqAyNexxTEhX8qTVXK5RkLoL0agjZOfoX/itA4PRhcT6QXCkrrronZlDPN/NzCwQj/4+MT/tG2tUsvC8MhqJ32hbL4GGFxyQFatPD8r6pWWL0syNq3JBbqcn4YPvAdquNHw6hWWNy3x3SHF2xvW8KoIdouenGpk/CKPiklhZCK6V9BEmJHqgWgUz4o1wJFh6TtadXnfbUOa2Rv623S1N0fZQPjHELhFONSBuXm09ijPdB1+VimccbJk6+pJyaCfKf8K2F2q68F4ZXAN8UYaeoUQ8JJvPMe8Q1syw7qzY96JjQH/auc8OJ2WsubmAHn/Cai/vRuMnfEjj9lbD3zNkzIYljZXQLLuol7okMoXQ3vBffQAvOJKQ6+5dLtuScu6bVbp57Klo2zXcQSBNdzUpn/4k7ghf5eg7bGQsZzloTbA9Rr7h/c/G6FVDlvNRLnefZ/2PRCKlJIdGF0ptHJDkugn1kr0VpdYndEFaXfg5hfBGWRD0+TTtwdR7FmxGBc9a+Dkd8Lic9fMBEdtHfcXw5HxMZtsr2QVIFFPRBX+AMpYTPvqDizva0lDuS9E3M6/uy0IfgowP9fVQZ6AdG2UtiRme+iPNpuZiTJXwPX4E5KoJXrtLyyxT2zVJ68FKBemmq+FC4UN1OWcdhvJNPE6h6RMQ+/cXOTZzlpSO7ndQheQqu3h8R1mbAyI19zmrXc4LDJWPOn6+lYo9xTFVFSVLdMOfhMIO/HYyVA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: When one of numa nodes runs out of memory and lots of processes still booting, slabinfo shows much slub segmentation exits. The following shows some of them: tunables : slabdata kmalloc-512 84309 380800 1024 32 8 : tunables 0 0 0 : slabdata 11900 11900 0 kmalloc-256 65869 365408 512 32 4 : tunables 0 0 0 : slabdata 11419 11419 0 365408 "kmalloc-256" objects are alloced but only 65869 of them are used; While 380800 "kmalloc-512" objects are alloced but only 84309 of them are used. This problem exits in the following senario: 1. Multiple numa nodes, e.g. four nodes. 2. Lack of memory in any one node. 3. Functions which alloc many slub memory in certain numa nodes, like alloc_fair_sched_group. The slub segmentation generated because of the following reason: In function "___slab_alloc" a new slab is attempted to be gotten via function "get_partial". If the argument 'node' is assigned but there are neither partial memory nor buddy memory in that assigned node, no slab could be gotten. And then the program attempt to alloc new slub from buddy system, as mentationed before: no buddy memory in that assigned node left, a new slub might be alloced from the buddy system of other node directly, no matter whether there is free partil memory left on other node. As a result slub segmentation generated. The key point of above allocation flow is: the slab should be alloced from the partial of other node first, instead of the buddy system of other node directly. In this commit a new slub allocation flow is proposed: 1. Attempt to get a slab via function get_partial (first step in new_objects lable). 2. If no slab is gotten and 'node' is assigned, try to alloc a new slab just from the assigned node instead of all node. 3. If no slab could be alloced from the assigned node, try to alloc slub from partial of other node. 4. If the alloctation in step 3 fails, alloc a new slub from buddy system of all node. Signed-off-by: Ming Yang Signed-off-by: Liang Zhang Signed-off-by: Zhigang Wang Reviewed-by: Shixin Liu --- This patch can be tested and verified by following steps: 1. First, try to run out memory on node0. echo 1000(depending on your memory) > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages. 2. Second, boot 10000(depending on your memory) processes which use setsid systemcall, as the setsid systemcall may likely call function alloc_fair_sched_group. 3. Last, check slabinfo, cat /proc/slabinfo. Hardware info: Memory : 8GiB CPU (total #): 120 numa node: 4 Test clang code example: int main() { void *p = malloc(1024); setsid(); while(1); } mm/slub.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/mm/slub.c b/mm/slub.c index 1bb2a93cf7..3eb2e7d386 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3522,7 +3522,18 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, } slub_put_cpu_ptr(s->cpu_slab); + if (node != NUMA_NO_NODE) { + slab = new_slab(s, gfpflags | __GFP_THISNODE, node); + if (slab) + goto slab_alloced; + + slab = get_any_partial(s, &pc); + if (slab) + goto slab_alloced; + } slab = new_slab(s, gfpflags, node); + +slab_alloced: c = slub_get_cpu_ptr(s->cpu_slab); if (unlikely(!slab)) {