From patchwork Mon Oct 28 11:53:42 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yunsheng Lin X-Patchwork-Id: 13853364 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 6C843D13596 for ; Mon, 28 Oct 2024 12:00:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D893A6B0095; Mon, 28 Oct 2024 08:00:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D16EA6B0096; Mon, 28 Oct 2024 08:00:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6DC26B0099; Mon, 28 Oct 2024 08:00:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7168C6B0096 for ; Mon, 28 Oct 2024 08:00:25 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2E1F9141DE7 for ; Mon, 28 Oct 2024 12:00:01 +0000 (UTC) X-FDA: 82722866814.17.C5F9513 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf19.hostedemail.com (Postfix) with ESMTP id 9A07C1A0003 for ; Mon, 28 Oct 2024 11:59:52 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=linyunsheng@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=1730116743; 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:in-reply-to:references:references; bh=PIvKsyT5LiI5apLvRpNTTV+XS0ge7DIXkJT1X+eybuw=; b=WNp8Gb5ib4JaFXHRfktrGGMmQV2bZ5Rc3oKFXvUr8Z/vq5dFwjqhmKe+WtxxMgvQMXebdI ouOzeUa9GTAN6Scekk8FcsLKO7Rypa1N7OV2mx0gZzV+KMqGI/uOGEzMzA7Wf61oP1omTq CGSriZUM/gI+Pto45KBdaPmfUmyNbK8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730116743; a=rsa-sha256; cv=none; b=WbxzfFsSax0pwN2+k91NSB0++3Bq4tlBbxHnPwQ6Zba9DJGLLu7UdR55VTOEO5ogQEHOFG hxhSKz833WU0hGRjNDblh+wl8XD0nQ3zrBONDLkPf+erPqY7h8YOJPxe9EMPjaAw3TpvHf WvJL1uHpVKNTcCP3xszaHbfAPN86S7E= Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4XcX5Q5TTFz1ynk7; Mon, 28 Oct 2024 20:00:26 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 785E4140155; Mon, 28 Oct 2024 20:00:18 +0800 (CST) Received: from localhost.localdomain (10.90.30.45) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 28 Oct 2024 20:00:18 +0800 From: Yunsheng Lin To: , , CC: , , Yunsheng Lin , Alexander Duyck , Andrew Morton , Linux-MM , Alexander Duyck Subject: [PATCH net-next v23 7/7] mm: page_frag: use __alloc_pages() to replace alloc_pages_node() Date: Mon, 28 Oct 2024 19:53:42 +0800 Message-ID: <20241028115343.3405838-8-linyunsheng@huawei.com> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20241028115343.3405838-1-linyunsheng@huawei.com> References: <20241028115343.3405838-1-linyunsheng@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.90.30.45] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 9A07C1A0003 X-Stat-Signature: eot91pw1x8wxqnj1pc8xwk1ict8d7qdg X-HE-Tag: 1730116792-792539 X-HE-Meta: U2FsdGVkX18bPdjGDiFZ6OYQ8eyba/o9ppkedY3lcDg5wMYdjyG5LngI/IZPBp57fLbuKl91RuW3or9VK+GYjwoWz6f/31CgYpQhcVVno0UPZpIX8WCU0ubUQPxgdsc2qiitVyRN40ZrOuKP2y0v+40B+4TVQQoHXY1J/hN0PZ7ObpxDcmEb1yNGyHvuCUkb+YBXwRGzXVkhxyhDlLZ2pzzWx0oiNrBeuR41srYdaw+RogQl4WAA4GulQSPEJ7BCM4oIrq1PLx6oMDDbA5ooAMOa5fFlyvpfn/k7KO5m93Iyep2oWggH7FOcISIos4nXMReCxK5KZPKnxBxoU7K5D/3pCCt2QPNUIkqdNCy41UuX5MWCIdXI0qkK7VqV32SFqEic4rnET8xOqx4eitEaZL06jlJko9FznlGmwzaq1rDRv9y7KKZmCsyBrnD75ISPItZY+FiTQP+6mL5uIjkIgRPXTEna/Oew6kHEX21rnV4DkjXPqZupPlJi/pUUucgVVWgAQQAwo6FQ+xNUA/17p4wmO//fVDtV5y76BjdrG4QO3vr3r8+o3wECF8YyQUdPOoj1FmRVJCXFuvVx1XxAvgi2sd0PlQ1dOUtEfuGOlXz7razGzWroffCc/xpL7LtDgaMYHALKivHHGeMIfg6Q0iqYN62u/F7dvpyuoNxkGehRDorTxpSkhQA/1FVoQaNMaoZ4owzbiTwUP2JSJReylnSOZ92gXtYTojcGZfSpqGDbFxEuZgTc6K8V8bhuIv1mF3dLe45NlCRq4A+HV/b7263K6+6gLHk4m7YKr5ToBg6IcPmNlP3toTOOBS82e16HFMcSzOlgwSTYaAMXcGFcBhWomhgGmnw4wQXDFKQ6nCOiTT8gTbERZldXVqjVIwK/Zf0F6vQyLWvxnYJWV+O48NnzH24MEj97zv7ZphqwnHzMy6HHPfw4ib+MviGIM8SETRkE65ok8/77e3LPCYH xYUY4eSn 96Zle5WqCG2FjszsrvAkkD80HTwLdinm4ECBLlaTaL0+tsuEmfWgFJrsdSzx+gwT/wJxtN46KLWUJH9zGv0OOgQKOg2Ml0nnhwSchdyg8e5oSGghZuKUFkIhdN5wLecOgBci0XvcOqJqNrspf4rd2bsm2mjxjIO3b7OKhPwzsqlxCMUlck8rGQHA/bWgUk8pOHGQAI3ds0PZBQOV7D9dnvLCuE6q/1s0zBLIRPT3Qt+LLxXwDMvX1cPKgrLc5NBaItAMqdH9CP1Y8L0dG2aFClSg0TEr3Vct+2VvocHAGnACxPYtgNQltqSOuMV2FenexHzgwNjbxhYfNI0CU99e2JQI9hE0mFKwk3RaeNP1XObifxYori1Sfzvu5IvSFJ1kQIiuX3cMSCIrDqK9NgN4cMj6WeHkn/8m8h9Jdj7SqpPXZVfE8zZpSIRLolPnrcm8V6RF6ZTMPa8lQEJgIGVlYtGl1zO3aRlCtNEX2gKaINorfZj/xZvoC8RHB360WSjdAXslp6dgSJEgU36jprP6UQTxx/4lnEwQs7PGf1moyFzClwUFOTq8RBw82cRtyT46Vu7R3 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: It seems there is about 24Bytes binary size increase for __page_frag_cache_refill() after refactoring in arm64 system with 64K PAGE_SIZE. By doing the gdb disassembling, It seems we can have more than 100Bytes decrease for the binary size by using __alloc_pages() to replace alloc_pages_node(), as there seems to be some unnecessary checking for nid being NUMA_NO_NODE, especially when page_frag is part of the mm system. CC: Alexander Duyck CC: Andrew Morton CC: Linux-MM Signed-off-by: Yunsheng Lin Reviewed-by: Alexander Duyck --- mm/page_frag_cache.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c index a36fd09bf275..3f7a203d35c6 100644 --- a/mm/page_frag_cache.c +++ b/mm/page_frag_cache.c @@ -56,11 +56,11 @@ static struct page *__page_frag_cache_refill(struct page_frag_cache *nc, #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) gfp_mask = (gfp_mask & ~__GFP_DIRECT_RECLAIM) | __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC; - page = alloc_pages_node(NUMA_NO_NODE, gfp_mask, - PAGE_FRAG_CACHE_MAX_ORDER); + page = __alloc_pages(gfp_mask, PAGE_FRAG_CACHE_MAX_ORDER, + numa_mem_id(), NULL); #endif if (unlikely(!page)) { - page = alloc_pages_node(NUMA_NO_NODE, gfp, 0); + page = __alloc_pages(gfp, 0, numa_mem_id(), NULL); order = 0; }