linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yunsheng Lin <linyunsheng@huawei.com>
To: Alexander H Duyck <alexander.duyck@gmail.com>,
	<davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>
Subject: Re: [RFC v11 09/14] mm: page_frag: use __alloc_pages() to replace alloc_pages_node()
Date: Wed, 24 Jul 2024 20:54:57 +0800	[thread overview]
Message-ID: <e7a9b79b-f1ab-4690-a3cf-4e9238e31790@huawei.com> (raw)
In-Reply-To: <e9982acd0eba5d06d178d0157aedfba569d5a09a.camel@gmail.com>

On 2024/7/22 5:41, Alexander H Duyck wrote:

...

>>  	if (unlikely(!page)) {
>> -		page = alloc_pages_node(NUMA_NO_NODE, gfp, 0);
>> +		page = __alloc_pages(gfp, 0, numa_mem_id(), NULL);
>>  		if (unlikely(!page)) {
>>  			memset(nc, 0, sizeof(*nc));
>>  			return NULL;
> 
> 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.
> 
> Rather than changing the code here, it might make more sense to update
> 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 benefit

I suppose you meant something like below:

@@ -290,10 +290,14 @@ struct folio *__folio_alloc_node_noprof(gfp_t gfp, unsigned int order, int nid)
 static inline struct page *alloc_pages_node_noprof(int nid, gfp_t gfp_mask,
                                                   unsigned int order)
 {
-       if (nid == NUMA_NO_NODE)
+       if (nid == NUMA_NO_NODE) {
                nid = numa_mem_id();
+       } else {
+               VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
+               warn_if_node_offline(nid, gfp_mask);
+       }

-       return __alloc_pages_node_noprof(nid, gfp_mask, order);
+       return __alloc_pages_noprof(gfp_mask, order, nid, NULL);
 }


> 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 and
> binary size by dropping the unnecessary instructions.

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.

[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=30306836, After=30306740, chg -0.00%




  reply	other threads:[~2024-07-24 12:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240719093338.55117-1-linyunsheng@huawei.com>
2024-07-19  9:33 ` [RFC v11 01/14] mm: page_frag: add a test module for page_frag Yunsheng Lin
2024-07-21 17:34   ` Alexander Duyck
2024-07-23 13:19     ` Yunsheng Lin
2024-07-19  9:33 ` [RFC v11 02/14] mm: move the page fragment allocator from page_alloc into its own file Yunsheng Lin
2024-07-21 17:58   ` Alexander Duyck
2024-07-27 15:04     ` Yunsheng Lin
2024-07-19  9:33 ` [RFC v11 03/14] mm: page_frag: use initial zero offset for page_frag_alloc_align() Yunsheng Lin
2024-07-21 18:34   ` Alexander Duyck
2024-07-19  9:33 ` [RFC v11 04/14] mm: page_frag: add '_va' suffix to page_frag API Yunsheng Lin
     [not found]   ` <CAKgT0UcqELiXntRA_uD8eJGjt-OCLO64ax=YFXrCHNnaj9kD8g@mail.gmail.com>
2024-07-25 12:21     ` Yunsheng Lin
2024-07-19  9:33 ` [RFC v11 05/14] mm: page_frag: avoid caller accessing 'page_frag_cache' directly Yunsheng Lin
2024-07-21 23:01   ` Alexander H Duyck
2024-07-19  9:33 ` [RFC v11 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc' Yunsheng Lin
2024-07-21 22:59   ` Alexander H Duyck
2024-07-19  9:33 ` [RFC v11 08/14] mm: page_frag: some minor refactoring before adding new API Yunsheng Lin
2024-07-21 23:40   ` Alexander H Duyck
2024-07-22 12:55     ` Yunsheng Lin
2024-07-22 15:32       ` Alexander Duyck
2024-07-23 13:19         ` Yunsheng Lin
2024-07-30 13:20           ` Yunsheng Lin
2024-07-30 15:12             ` Alexander H Duyck
2024-07-31 12:35               ` Yunsheng Lin
2024-07-31 17:02                 ` Alexander H Duyck
2024-08-01 12:53                   ` Yunsheng Lin
2024-07-19  9:33 ` [RFC v11 09/14] mm: page_frag: use __alloc_pages() to replace alloc_pages_node() Yunsheng Lin
2024-07-21 21:41   ` Alexander H Duyck
2024-07-24 12:54     ` Yunsheng Lin [this message]
2024-07-24 15:03       ` Alexander Duyck
2024-07-25 12:19         ` Yunsheng Lin
2024-08-14 18:34           ` Alexander H Duyck
2024-07-19  9:33 ` [RFC v11 11/14] mm: page_frag: introduce prepare/probe/commit API Yunsheng Lin
2024-07-19  9:33 ` [RFC v11 13/14] mm: page_frag: update documentation for page_frag Yunsheng Lin
     [not found] ` <CAKgT0UcGvrS7=r0OCGZipzBv8RuwYtRwb2QDXqiF4qW5CNws4g@mail.gmail.com>
     [not found]   ` <b2001dba-a2d2-4b49-bc9f-59e175e7bba1@huawei.com>
2024-07-22 15:21     ` [RFC v11 00/14] Replace page_frag with page_frag_cache for sk_page_frag() Alexander Duyck
2024-07-23 13:17       ` Yunsheng Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7a9b79b-f1ab-4690-a3cf-4e9238e31790@huawei.com \
    --to=linyunsheng@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox