From mboxrd@z Thu Jan 1 00:00:00 1970 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 9A2C9C3DA4A for ; Wed, 14 Aug 2024 18:34:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25D026B007B; Wed, 14 Aug 2024 14:34:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2161D6B0082; Wed, 14 Aug 2024 14:34:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 086826B0083; Wed, 14 Aug 2024 14:34:52 -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 DB9406B007B for ; Wed, 14 Aug 2024 14:34:51 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AAC55A8443 for ; Wed, 14 Aug 2024 18:34:49 +0000 (UTC) X-FDA: 82451702298.06.39849E4 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by imf06.hostedemail.com (Postfix) with ESMTP id A82A318000A for ; Wed, 14 Aug 2024 18:34:46 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BYeGY1UG; spf=pass (imf06.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.167.180 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723660474; 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:dkim-signature; bh=s7fBiR5n5YVska8nCpcg/V51Z88Uf3Sx/H0PEnfkJY0=; b=4xCJP3A4no5bmEWNFb4d9bAEDumhp7E/bxCY0KvWKjQvfz29slBedT0MZyPrLff8kKyBAM etiXSFs5JZFtNBIuHLeq+WxLifBFxtvUEOl0tVEimbbo4McbC1OtRnFcjTiql4H/CLZatN h/V2+j3wBFbiDfXLuWYU7CGAKAiYwWE= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BYeGY1UG; spf=pass (imf06.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.167.180 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723660474; a=rsa-sha256; cv=none; b=YIq7zkSS1j9ddiQqfCFlnkCzBzjtDXfxPeVTSjwv8Bvip7JWUodhbU8G+G3Tw83wB9emhy 8h1TDkN/xpv2ki9b6LuzIsvwuu6Eebm45UtlaMCS5VQzne7kuXL1ryLt0GBQD2dMs5+fEr nc1w3wEhvHzyPn9meuFF+M+8JyFQWyE= Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-3db145c8010so75108b6e.3 for ; Wed, 14 Aug 2024 11:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723660485; x=1724265285; darn=kvack.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=s7fBiR5n5YVska8nCpcg/V51Z88Uf3Sx/H0PEnfkJY0=; b=BYeGY1UGK69LsifHWz75BaC+uzHNBycWr1SmogpZg17W9GhmagK+86jY5LAmm54/Os Uo59xA9ogAEFdYKUFoukzxkheHBmVuB8RGTgrKIpi3f8uIt3OEIYzBSZMLJSBqQnwXQk wE1vPhWd94xzotOc9SAugjjDTWvMxNGI7ylowgmyWCCrSDLh8ktR3QNjWSO7V0we+LOg oc2yCjNZ1sp4Magyy7jxDa6PxrMqklpWnpQU+NSr2lkS96X6XHOvV9kLH+nC/SmWVPQF xxGocjv7xZN7e+G9aD9swizS3uU0pVx6yFLBiLuaBaxFhQWY6OmeRgz3KyXhLWmCj25b BYYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723660485; x=1724265285; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=s7fBiR5n5YVska8nCpcg/V51Z88Uf3Sx/H0PEnfkJY0=; b=UQ8NFkL3SLGLlTik78mkpaOiiFucdj4iUKGCySxJo+MPkjMf9qxrev6O+S97ulsiTq fGAG8C53m0bPgVkh/kCMqmLfRwKXBNiwAJjRX7wBcMJxUy+pN8X4m0mXp8vLb43AxU6z y8aWJcNJGOFVcJUrl8YrjwfzQD4gKOCdM2Z/fz+dWapXMTaaENuLP4aRSjg7KNSEePsi +DBCQHbzHeM9iJxpqBCIqSrTnMZaNvbXXomVjsm3Iibyix+PlB/rg1h3LTIG1ge9kEXw XJGPG3qhRhUASTNQ2ZI5mm6RCfmfegR5eeCJBaimanY/HGiT62uksxe/oOcK3kc2ESKp sinA== X-Forwarded-Encrypted: i=1; AJvYcCX7QBHjyjLaMSj0xga5To5RES7Y12TjpdRv8lC/RECPRpnpDM9JL8OQdb6mmDAerRikBOsaxR/SAg==@kvack.org X-Gm-Message-State: AOJu0YzA7NMQF9AJzCNqC4UZzaI/Bu/y2ZgrnsNaIhgQYZVuXyDtcunW x9i+EfE/pwtMNkENg5l2viCV9OWP4dDrgvEgOsz0ApEzOhOGIJCj X-Google-Smtp-Source: AGHT+IGp8VHH+vp2sKO+De9Eidc0HJA7E4M5OPTwjtvkmOM1+JzDyIk439bt2yD24VQafvrTKUyYKg== X-Received: by 2002:a05:6808:3a15:b0:3d5:2afc:94f5 with SMTP id 5614622812f47-3dd298de1efmr3814010b6e.10.1723660485303; Wed, 14 Aug 2024 11:34:45 -0700 (PDT) Received: from ?IPv6:2605:59c8:829:4c00:82ee:73ff:fe41:9a02? ([2605:59c8:829:4c00:82ee:73ff:fe41:9a02]) by smtp.googlemail.com with ESMTPSA id 5614622812f47-3dd060bc374sm2194680b6e.51.2024.08.14.11.34.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Aug 2024 11:34:44 -0700 (PDT) Message-ID: <31546afa1e9b715f01e43a1ef9389415a8f8b05c.camel@gmail.com> Subject: Re: [RFC v11 09/14] mm: page_frag: use __alloc_pages() to replace alloc_pages_node() From: Alexander H Duyck To: Yunsheng Lin Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Date: Wed, 14 Aug 2024 11:34:42 -0700 In-Reply-To: <5df99f22-801c-4b0a-a3bc-0e2e0fadfdd3@huawei.com> References: <20240719093338.55117-1-linyunsheng@huawei.com> <20240719093338.55117-10-linyunsheng@huawei.com> <5df99f22-801c-4b0a-a3bc-0e2e0fadfdd3@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: trbi3qbsh7kguucttgtuo74qqkw44f8z X-Rspamd-Queue-Id: A82A318000A X-Rspamd-Server: rspam11 X-HE-Tag: 1723660486-191717 X-HE-Meta: U2FsdGVkX1+LUJRwrjmAJjW21sbiE9DErjc1/5IU+EqYEN9zJBwMgpu8zz6YG/ihGyuauxC9BLCzhDPi5B9GqYHsKkAwjM2dRfdCL7pzl6evK6Eqq/riDBN51ZMv0mFxw4mN06brV6wL+4Vnoy8DhrodOOCxFysHnQ29hGIyQ7gWhvv3vts9NB+4m6arp6cFaWK+y9pwddxB+Iox3AFR5ihvZYIPVH5Y4oQIKvlfhhYot94udJXXA5MeSYOhlQh3kv3kJSBDGdxIEr8IGluiq7Msbz9EtoyvXKvoLXYlkgKYMBcUfxRhYeRY1RIuRuOxaSGrCUTunHtXlr6u+GEnNhdfpLtdh6ttPxmy2/N3mZoNgthsboGjK+7fdtmjCYnnZRCevaDwvbx2Raq+SO3hD4ODIXvNtz0qzpYheij/mVz4ciG87VeMoAeRsmF/x0EASx82zSvjsnlUxKgH8aUR3q8mOyrLbeIJMaTwjw3IEDBLlM5vj1nCUSbr11GZAH6QM9RF58m4Qzxf6SsPQg4xS/6yErKBxTWDVXtsUDpCvmlfQo57t3S80mP+wG3uulkpDb5IkekFiNc1fdzBwqXwGpQMeBM4q8otPcF2uyMxx0W3sqcBvqxrwPiaz7sNbC/RZX4m2bJxtchIGX4MBZv002IjFhUyH3w1T4JQIKagtaW4sixy30FfWRQPAJq53wrqgzLVep4NXGSlvZF7B0uu6vDpC41z2oh5LbNqbvH/XHJwz+PbPw8JhHlNX/AxFIocYvFzW7k/+VAYvdsR7rqtbeO2Tqo+FVIKBL0i45P03qq8rkJpQKGZMRInnuGgkRO0F4ddbFm6XVUYwdiygnarLN1rtNV7Ahr9oT63A1CSzcnJA5IeiD0gYtGQjuqRYPLWEzwOb5VxLbVtRVWQo8+HyQSF/RoDLTuXgxJDohmt8S40nDLsrMwCbx3+AZuPesHcJOCFpwErbF4dR3Is/Du ct+QWzVg XwRTGazPNZKhUfyHNMcfLSBeXpDdMkXg6lEuQDsYxw6tPhl9u4SHIiFoOx1cUjzysi7eKdwD7VL8NG436e9d0uIyslyO9DpxTeikDecV7TjKKiHJ1WHemnnh/1rxjbT2CWROPVO36x8qOzOkeULOmhq0SNSFQDGYW0lOtpfgIuFTaT7fz2afrdpDUWhrWZYH/Jr9LfPqr3pc8Co4WBlRgErYUMM9LhPpcljRfo7+cqybOZTJs2wvVQLygwGchx4UguZwKlPcuDzV/9NoyGSVfHipsrg5ePMic5GPgIEKim+S/SzvAhVC4DlNHE3AEn8sC6oMRTDMnagme34iwLEUG4mp1E/YaBF9d+2ERm0zIxyIZYVFzZCIKNZIWmOQiLH5zSH3u0YLMnIg+RYYxU0sZ5e9iA+e1dbdywow5m9QF5RZXWpTSnX7On8z0vY0eEc+orrQ9HZgqLifitYdqPmkxde8/0Byb3VUQUrPfh0nzJif6E6w= 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: On Thu, 2024-07-25 at 20:19 +0800, Yunsheng Lin wrote: > On 2024/7/24 23:03, Alexander Duyck wrote: > > On Wed, Jul 24, 2024 at 5:55=E2=80=AFAM Yunsheng Lin wrote: > > >=20 > > > On 2024/7/22 5:41, Alexander H Duyck wrote: > > >=20 > > > ... > > >=20 > > > > > if (unlikely(!page)) { > > > > > - page =3D alloc_pages_node(NUMA_NO_NODE, gfp, 0); > > > > > + page =3D __alloc_pages(gfp, 0, numa_mem_id(), NULL); > > > > > if (unlikely(!page)) { > > > > > memset(nc, 0, sizeof(*nc)); > > > > > return NULL; > > > >=20 > > > > So if I am understanding correctly this is basically just stripping= the > > > > checks that were being performed since they aren't really needed to > > > > verify the output of numa_mem_id. > > > >=20 > > > > Rather than changing the code here, it might make more sense to upd= ate > > > > alloc_pages_node_noprof to move the lines from > > > > __alloc_pages_node_noprof into it. Then you could put the VM_BUG_ON= and > > > > warn_if_node_offline into an else statement which would cause them = to > > > > be automatically stripped for this and all other callers. The benef= it > > >=20 > > > I suppose you meant something like below: > > >=20 > > > @@ -290,10 +290,14 @@ struct folio *__folio_alloc_node_noprof(gfp_t g= fp, unsigned int order, int nid) > > > static inline struct page *alloc_pages_node_noprof(int nid, gfp_t gf= p_mask, > > > unsigned int order= ) > > > { > > > - if (nid =3D=3D NUMA_NO_NODE) > > > + if (nid =3D=3D NUMA_NO_NODE) { > > > nid =3D numa_mem_id(); > > > + } else { > > > + VM_BUG_ON(nid < 0 || nid >=3D MAX_NUMNODES); > > > + warn_if_node_offline(nid, gfp_mask); > > > + } > > >=20 > > > - return __alloc_pages_node_noprof(nid, gfp_mask, order); > > > + return __alloc_pages_noprof(gfp_mask, order, nid, NULL); > > > } > >=20 > > Yes, that is more or less what I was thinking. > >=20 > > > > would likely be much more significant and may be worthy of being > > > > accepted on its own merit without being a part of this patch set as= I > > > > would imagine it would show slight gains in terms of performance an= d > > > > binary size by dropping the unnecessary instructions. > > >=20 > > > Below is the result, it does reduce the binary size for > > > __page_frag_alloc_align() significantly as expected, but also > > > increase the size for other functions, which seems to be passing > > > a runtime nid, so the trick above doesn't work. I am not sure if > > > the overall reduction is significant enough to justify the change? > > > It seems that depends on how many future callers are passing runtime > > > nid to alloc_pages_node() related APIs. > > >=20 > > > [linyunsheng@localhost net-next]$ ./scripts/bloat-o-meter vmlinux.org= vmlinux > > > add/remove: 1/2 grow/shrink: 13/8 up/down: 160/-256 (-96) > > > Function old new delta > > > bpf_map_alloc_pages 708 764 +56 > > > its_probe_one 2836 2860 +24 > > > iommu_dma_alloc 984 1008 +24 > > > __iommu_dma_alloc_noncontiguous.constprop 1180 1192 +12 > > > e843419@0f3f_00011fb1_4348 - 8 +8 > > > its_vpe_irq_domain_deactivate 312 316 +4 > > > its_vpe_irq_domain_alloc 1492 1496 +4 > > > its_irq_domain_free 440 444 +4 > > > iommu_dma_map_sg 1328 1332 +4 > > > dpaa_eth_probe 5524 5528 +4 > > > dpaa2_eth_xdp_xmit 676 680 +4 > > > dpaa2_eth_open 564 568 +4 > > > dma_direct_get_required_mask 116 120 +4 > > > __dma_direct_alloc_pages.constprop 656 660 +4 > > > its_vpe_set_affinity 928 924 -4 > > > its_send_single_command 340 336 -4 > > > its_alloc_table_entry 456 452 -4 > > > dpaa_bp_seed 232 228 -4 > > > arm_64_lpae_alloc_pgtable_s1 680 676 -4 > > > __arm_lpae_alloc_pages 900 896 -4 > > > e843419@0473_00005079_16ec 8 - -8 > > > e843419@0189_00001c33_1c8 8 - -8 > > > ringbuf_map_alloc 612 600 -12 > > > __page_frag_alloc_align 740 536 -204 > > > Total: Before=3D30306836, After=3D30306740, chg -0.00% > >=20 > > I'm assuming the compiler must have uninlined > > __alloc_pages_node_noprof in the previous version of things for the > > cases where it is causing an increase in the code size. > >=20 > > One alternative approach we could look at doing would be to just add > > the following to the start of the function: > > if (__builtin_constant_p(nid) && nid =3D=3D NUMA_NO_NODE) > > return __alloc_pages_noprof(gfp_mask, order, numa_mem_id(), NUL= L); > >=20 > > That should yield the best result as it essentially skips over the > > problematic code at compile time for the constant case, otherwise the > > code should be fully stripped so it shouldn't add any additional > > overhead. >=20 > Just tried it, it seems it is more complicated than expected too. > For example, the above changing seems to cause alloc_slab_page() to be > inlined to new_slab() and other inlining/uninlining that is hard to > understand. >=20 > [linyunsheng@localhost net-next]$ ./scripts/bloat-o-meter vmlinux.org vml= inux > add/remove: 1/2 grow/shrink: 16/11 up/down: 432/-536 (-104) > Function old new delta > new_slab 808 1124 +316 > its_probe_one 2836 2876 +40 > dpaa2_eth_set_dist_key 1096 1112 +16 > e843419@0f3f_00011fb1_4348 - 8 +8 > rx_default_dqrr 2776 2780 +4 > pcpu_unmap_pages 356 360 +4 > its_vpe_irq_domain_alloc 1492 1496 +4 > iommu_dma_init_fq 520 524 +4 > iommu_dma_alloc 984 988 +4 > hns3_nic_net_timeout 704 708 +4 > hns3_init_all_ring 1168 1172 +4 > hns3_clear_all_ring 372 376 +4 > enetc_refill_rx_ring 448 452 +4 > enetc_free_rxtx_rings 276 280 +4 > dpaa2_eth_xdp_xmit 676 680 +4 > dpaa2_eth_rx 1716 1720 +4 > ___slab_alloc 2120 2124 +4 > pcpu_free_pages.constprop 236 232 -4 > its_alloc_table_entry 456 452 -4 > hns3_reset_notify_init_enet 628 624 -4 > dpaa_cleanup_tx_fd 556 552 -4 > dpaa_bp_seed 232 228 -4 > blk_update_request 944 940 -4 > blk_execute_rq 540 536 -4 > arm_64_lpae_alloc_pgtable_s1 680 676 -4 > __kmalloc_large_node 340 336 -4 > __arm_lpae_unmap 1588 1584 -4 > e843419@0473_00005079_16ec 8 - -8 > __page_frag_alloc_align 740 536 -204 > alloc_slab_page 284 - -284 > Total: Before=3D30306836, After=3D30306732, chg -0.00% One interesting similarity between the alloc_slab function and __page_frag_alloc_align is that they both seem to be doing the higher order followed by lower order allocation. I wonder if we couldn't somehow consolidate the checks and make it so that we have a function that will provide a page size within a range.