From patchwork Fri Oct 18 10:53:45 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yunsheng Lin X-Patchwork-Id: 13841628 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 96CF0D2FFF2 for ; Fri, 18 Oct 2024 11:00:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 309A66B0098; Fri, 18 Oct 2024 07:00:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B76E6B0099; Fri, 18 Oct 2024 07:00:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A6AE6B009A; Fri, 18 Oct 2024 07:00:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id F24BF6B0098 for ; Fri, 18 Oct 2024 07:00:34 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 430651C6CB8 for ; Fri, 18 Oct 2024 11:00:21 +0000 (UTC) X-FDA: 82686429210.25.DE4416A Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf03.hostedemail.com (Postfix) with ESMTP id 266AF2002C for ; Fri, 18 Oct 2024 11:00:26 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf03.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729249198; a=rsa-sha256; cv=none; b=MCL1FQiPhfhfaraz2GEjOTTfVzOPUm1rU7CN146yNzV7U7e6NneQVzMA9V3MEonNON7pkw J7SQfVMHwIMg2CcXFsSxCDVdQE3g0GoLHaIBBiIg1Os62N4wxlp37sQ04kh/BxlV6cMUpZ Wrm7ZYMI3VcxE9gNwRZaaAJzFY5IiHs= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf03.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729249198; 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=oxu8hSzwpd+A1v2yAfTKABFCS6bAIPSzf9AqtIU4SqM=; b=t00d/iHTyniJ0RXM1g++ZHOxfmRxjNn/+Tvj3WkaBU8SZ6Iq50TM+F2acKKUHWVJ3Wt1eU r0A76CbzZ41+PMIBVZMVH6X8YHyr2ms71hGviNBcf9OnQo0nOmmfPb+HwhqV6W0Mpz0gbD P/BaXBRTgVfPfNQFiwR1XDTWQJ690oE= Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4XVMBd5j32z10Ng8; Fri, 18 Oct 2024 18:58:33 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 37A481800D9; Fri, 18 Oct 2024 19:00:29 +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; Fri, 18 Oct 2024 19:00:23 +0800 From: Yunsheng Lin To: , , CC: , , Yunsheng Lin , Alexander Duyck , Alexander Duyck , Andrew Morton , Subject: [PATCH net-next v22 08/14] mm: page_frag: use __alloc_pages() to replace alloc_pages_node() Date: Fri, 18 Oct 2024 18:53:45 +0800 Message-ID: <20241018105351.1960345-9-linyunsheng@huawei.com> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20241018105351.1960345-1-linyunsheng@huawei.com> References: <20241018105351.1960345-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-Rspam-User: X-Stat-Signature: wkns5yzkom1b835pftcgbunqjrk5zipp X-Rspamd-Queue-Id: 266AF2002C X-Rspamd-Server: rspam02 X-HE-Tag: 1729249226-613307 X-HE-Meta: U2FsdGVkX19MWHwnpxFFv+U2zDveRbg+65K232ZZPUZLJ4XEgfUpsWlYcQUiCFyaf5jM5BlqGV+m9VzGoeacVf0Hx60WH4Xes9VSm7MRbWx5nndLFC+uFwa+CQOSQir2ilvmXLaAkix9GFIx5svrlsLqePe7vLsnOdwqYR47KR5FYo2MiHW3cYwR55r7SYReRWPCPykvtlURYJtD9+5eE8XtfH/lP9RkacK2dkFkYUR7PCD1kidUIMAkRPqFtbanes1rUo6++sBalGyurC2bVYVhxZfmhcdcoko+vcZeAT9UDEpZbcc/Syl/gK57v2jJw1Mu/TIBVJ0iAdlEhmFrqjr6BVTA/yck8DUaHmEQANaD/+HOoAZtlfdIFYUkFWqu+xgkX1XI4Ofb+1JnQXTl55i49hdhZPSUhHpMejP7Hq/v4qRicYavw10ZPQx0jjJFw2+iNWf2S24G0kXAex3YzqBYrW8AXvTSJ53MWOYwqpm3GdRW/mm7By8scMpicSoq6j7Hp9uSZanJEATFJNmOGDVs8V9p9Svf4IBaV7r0uKoSP1zEvEyA89QUTMB6W13gpJEZpAA7kDuIgKcffn+tT/PIWqhG9J14Pdm63SCO+y40RO/SnQjRGykpQ/BNOqR6OQ2dwmpiX+uBLBxRP09zxqOMLBVwRIn6AMV7bWb0fPnDzgZ9lRDpN8Sl6GbBuws3lSCJSgGLCHH3mIE+/xvgTzbAVRFkMUUQJWyn5zMtqccjjfOhif6DY4FfRWTQ7QtVNwochH0NbQb7ozVp3MgJp57aA1MVcL0gQcuaT66sVumd90vzPy8YarHfn78s5KRkQFLdGfYAt3rYDTcc1EBQQW+61im40vHIfkLzO0h6cWagitkcj151kFukPYVLoWmiQbyA1VI0lMqey/2iFelF3ISxDm2oWGpxZQ9H/K31qr+Dg0M38LeSdPnYPVRuzowzAbTa4kx5C7thvEvGOxv uI/WUiLX UUXbU0d/2xh3QdlU7zozvUZONyq4SYRvw3TcKDPIlGNtTRRNOWdESpwcrEUtTAgHs6IF8hJZv3/+y0aP+kHzMxQdNtar3+Rcy0sxiyk5WLvPPz7j/G85SUSr38+UN2Kma1rSEYARmb3h4KbjJdn8uOz5pMTfrPfR3roHm2APRqh3eUiiS7q/4FlNmK2Wq+G4NL1eqbQlNmaB6XxtQKDcd8LDBkWhCgV6mkF0JzEyRzIm2nfWu8DNtJA2EFBVwA5xbsZO+1JCcL94/4XSkHUSocL75Fz52dx/Rmx52ZGBQrZeq9Saum9MmSqvf0KPcbEz1UU0FWoG9r+nXhe9xhQaf5Kye6s1sbD9WSqaeqGKdAHYk4UzulEbXkAspbK5hegmYran1yVdFWMnzuMNiS9bSDecXrnC7Mv6d73Fz+0yqfmklx1yQEAqU4Z84kqXsANx4tq8vDP4v8tXALtmW5i9xvzATFg== 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 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 a852523bc8ca..f55d34cf7d43 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; }