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 87C06C54731 for ; Tue, 27 Aug 2024 15:31:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2595A6B008C; Tue, 27 Aug 2024 11:31:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 209826B0092; Tue, 27 Aug 2024 11:31:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D0B66B0093; Tue, 27 Aug 2024 11:31:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E4B9E6B008C for ; Tue, 27 Aug 2024 11:31:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9BBBA1619F4 for ; Tue, 27 Aug 2024 15:31:36 +0000 (UTC) X-FDA: 82498414992.03.35937B0 Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by imf15.hostedemail.com (Postfix) with ESMTP id C6173A002D for ; Tue, 27 Aug 2024 15:31:34 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PfJKdWwp; spf=pass (imf15.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.166.46 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=1724772626; 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=WqcUNaxQm25GRpp+jV0VmnGAyj/IWoEm4mVeyn3fA50=; b=oVPgxE4q/YiqQIOlvBqDtB2OieOaeHQqdFRYhaixIA6VbrQS5mfl052xIxyo/6KHn/+WtE rU2acdtYqrogoKrXI6eYTxRU1Xpwq60H4Hc8PIA75P6rDC7IMXCxKJNNTGB3r1fzuKMMBt l8udYTnZrhXmlIuW1TEgOd7uoCnBZMk= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PfJKdWwp; spf=pass (imf15.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.166.46 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=1724772626; a=rsa-sha256; cv=none; b=RQi/+7DeroHD+9fVHvLeyJsOo22V/8OkRwysdvfN48Gs/ycdxukLcXvPFo9eYZrNEnwj0U AWM09FbrDMouxs08owPEcfs6zqUXzzhjFdNjJCf0+RjhVmPyMVSBsK8BPGFdbS9+e+P8XY fRe4gxNWNq2qf69B8hDyXslNYmx9zCo= Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-829e3fbcb87so81527739f.0 for ; Tue, 27 Aug 2024 08:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724772694; x=1725377494; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WqcUNaxQm25GRpp+jV0VmnGAyj/IWoEm4mVeyn3fA50=; b=PfJKdWwpdkiz4QgHXi93ix2pWOauNAft0jmwZ2mrTazSajywlpZ/Js4CUgLX2NCAhF ed8DXJj6I1zm5BluldLGjflw4JDCaKs+Gj8VsdshLOyR+AlgEi0xwI0WC5lSbHRGh4Au xnmKPezO5Y5Qv6kYAl/o5LwC1LrQ/+1YWbYi1Kbr/S3W0tIMP/2IPebvuc2L5G6LUUnf NS0GYIiFb25GvfxGuRWQp1dsH4A9sa/D9ONCQulf7KZLR0wQpNBj/9F+nh+DezXxyxeD fuWp10gDKbJ+ZYAI1apCj03VfF4XdqjjmK+XLynjMaCUoIFuJDz9maEl2fzQy3xhX1Y7 Ivfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724772694; x=1725377494; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WqcUNaxQm25GRpp+jV0VmnGAyj/IWoEm4mVeyn3fA50=; b=WUhXWp6dcG5Wr0M3vHruO3KtZvkO6xs+2XhHvKbTM/S6QQOl3y0VNmd85X2ULWlp7b dimPKsUagyXLyh3LHvePSOy5+yNgRRnI3oFeADlLnJmqsRYseWC4mdgj6+N9M58x1QFt Atdr8JGDhYWG3D8Snzdw3wo+1xhPXFRojGGreUt5oKFldB+TXCIFFHlHp8BwUergO9wk UiCo4KEzjAhmCxC3ZgpzpgdfAohaxLbFglgE4NDQhnujN2xhN18wE7ulitehuvPbTUoT V3yMOwfWJ1GkltrGQ5t7IYDHMtCrxf8inkNqwD78fpE4V5cdB3suM7X+a3VfoSoiC5U1 kO3A== X-Forwarded-Encrypted: i=1; AJvYcCWUWoUEe+H60Ah8lTygt5od/cFxfZiEPs+WJNGeyyGKntWedi8RM+MjxLHhy9AB1oSXeTVPO1FuuA==@kvack.org X-Gm-Message-State: AOJu0YxRuRb+6d7ewiyM+XJV+G7+ExcsDgZYzSma9QeBv0uR8TSdcGJO UJxOEaGBtuvw/0wvP62RNWEqNTlpr6r3DCaKt21lnRcd02OSYNq08RAJnOg5+wmHeimCbMC9HGn fP3BVGWuND+EWo938YQW8scuGxok= X-Google-Smtp-Source: AGHT+IGYv3dP4E+8xvHvi2ISRorEeU+/82nOF/XKfiOihGEHwbyFnfJnqy2jdgRv1T29v0FuP0fzreKhk4djPZ4vfnY= X-Received: by 2002:a92:c54f:0:b0:397:70e7:143b with SMTP id e9e14a558f8ab-39e3c98f968mr156852035ab.14.1724772693457; Tue, 27 Aug 2024 08:31:33 -0700 (PDT) MIME-Version: 1.0 References: <20240826124021.2635705-1-linyunsheng@huawei.com> <20240826124021.2635705-9-linyunsheng@huawei.com> <67c7c28d-bbfa-457d-a5bb-cb06806e5433@huawei.com> In-Reply-To: <67c7c28d-bbfa-457d-a5bb-cb06806e5433@huawei.com> From: Alexander Duyck Date: Tue, 27 Aug 2024 08:30:55 -0700 Message-ID: Subject: Re: [PATCH net-next v15 08/13] mm: page_frag: use __alloc_pages() to replace alloc_pages_node() 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: tw9xf3y9pz833amypjdrojmemhxnpwgf X-Rspam-User: X-Rspamd-Queue-Id: C6173A002D X-Rspamd-Server: rspam02 X-HE-Tag: 1724772694-503109 X-HE-Meta: U2FsdGVkX1/R1zi5uv5mK54O9gswtYfMZL5bbH4oybLN55NoEfEIyQjU0ivCKhdNgEvu6Qc8YuY511saHyRBov10OuTt0/6qgjUkysiwT5fW/gsWgM9N1gex7fwwpEFLtiS2KcNvVC62QauPAQOGM/WgxQuEcRcnQ52Sao3GzGqafptgtjISPgScnBI2lNqBvnIfjrMhxcU66pLQ4norkBIo6Vg3H3RmNzh+V+KCNhIelC2c2lpMApApbD3iQ6iEpFhco9nHr5kkFGXPLd97l3v77Q55sgN52JClOVe1Nibqp5azIwDvCvmddaw4lQJcXlBIPKNVN42CX1PTtA9NmNQ+YREqGtZSflqAAUXbaK4Om01QCCFoFipwTD+hejuDNn1wDhGgs9mDl1MSgfqPTlunHcDZaPXUjeriY5IF1neDQfHzfl0UlGnMzlHhv/cumvhepzvykuAsvosmhDVvzN4xOYMo7lxCNBM2Cd25w7inKygxVxh1J4dixYrU3G0apjfw6vDa2B+tgjsaA5Yr67kRMmxs+luYLlO9ZzKW1thts85DvtHI5XCqC0wnvYtOVjmJU4yuuvCHGfkjbphZI6KmKTQf5QmCbcG2/Jb4WxO1aI4t1ocTM+1BkJPZ4B8uZWnSljf65fmQH6BZ4vAVbj18XnT45vDSCEB3yRRErGaqj1nROy+ljimZDwomEWaJXQUtDreCPI4ajAHXug5iCODA3Njef7DgfoLWADi3rBnVgdaieKT0qre0PELhjQ0bMn2fbQJANCMHlfq0n6waiMyBACMv8STmT1nhsw+8eiNnyziZDONeN0wol4yyQLK2FTgPY4+4EXbQLxq2XVTPhdNqLA1whIQUXGN0DYXweOdHb2kgSD4s79nVsvDZs843GZrbX52S60d+mxH1IdS+P9BwpzCeAvNXWA0E5ePZlqX+86wo1YmR7bq4Y51mx13bJOLsrJSq0cam7zXiFOC WHcLSbFX KNQmKKsr6blIYPCp0Od7FloW5UPwMi/RBphHw7j6X6C6lqDC/URNkaRsb5YLEn6A01D4yuELg4oGzz4iDRTJDXwM2tO79rYEbN4lQFuL3aExre5QrVMwSL0dpio27za7RNIin/aLu+0row7bFAFXRmndfuA+2Ku6GBu49HRnk3LqqjQJ3MNYNitiOMc3iZ9zINdL1VMqNiHDKuoEWDX92M/Tv9pdBAiPWcAhSyuAKjN44hzEoFqjLMkH8gBjumVDR+/EjthCeeFTr7SnYIt0aFiZ3yVYEOCbuqyB3bH4J0x0bof3N/KKtc62C/sNTKPMlLojUr6/sH4VJUDPyopuzEPzSyRDx1wmYhmuna8kekUVh8ra7BG5eU4134XDlIMRlWcpCTb++KaZXZoC+OjfNg5b/lcyWjCmHUtnUERNaKcVsWjGvMVDjxYwoXpIsaF/yq6MYQb3vGiyyMpFlxUW2H4MTg+up7zLauUce 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 Tue, Aug 27, 2024 at 5:07=E2=80=AFAM Yunsheng Lin wrote: > > On 2024/8/27 1:00, Alexander Duyck wrote: > > On Mon, Aug 26, 2024 at 5:46=E2=80=AFAM Yunsheng Lin wrote: > >> > >> 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 > >> --- > >> 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 bba59c87d478..e0ad3de11249 100644 > >> --- a/mm/page_frag_cache.c > >> +++ b/mm/page_frag_cache.c > >> @@ -28,11 +28,11 @@ static struct page *__page_frag_cache_refill(struc= t page_frag_cache *nc, > >> #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > >> gfp_mask =3D (gfp_mask & ~__GFP_DIRECT_RECLAIM) | __GFP_COMP = | > >> __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC; > >> - page =3D alloc_pages_node(NUMA_NO_NODE, gfp_mask, > >> - PAGE_FRAG_CACHE_MAX_ORDER); > >> + page =3D __alloc_pages(gfp_mask, PAGE_FRAG_CACHE_MAX_ORDER, > >> + numa_mem_id(), NULL); > >> #endif > >> 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)) { > >> nc->encoded_page =3D 0; > >> return NULL; > > > > I still think this would be better served by fixing alloc_pages_node > > to drop the superfluous checks rather than changing the function. We > > would get more gain by just addressing the builtin constant and > > NUMA_NO_NODE case there. > > I am supposing by 'just addressing the builtin constant and NUMA_NO_NODE > case', it meant the below change from the previous discussion: > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 01a49be7c98d..009ffb50d8cd 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -290,6 +290,9 @@ struct folio *__folio_alloc_node_noprof(gfp_t gfp, un= signed int order, int nid) > static inline struct page *alloc_pages_node_noprof(int nid, gfp_t gfp_ma= sk, > unsigned int order) > { > + if (__builtin_constant_p(nid) && nid =3D=3D NUMA_NO_NODE) > + return __alloc_pages_noprof(gfp_mask, order, numa_mem_id(= ), NULL); > + > if (nid =3D=3D NUMA_NO_NODE) > nid =3D numa_mem_id(); > > > Actually it does not seem to get more gain by judging from binary size > changing as below, vmlinux.org is the image after this patchset, and > vmlinux is the image after this patchset with this patch reverted and > with above change applied. > > [linyunsheng@localhost net-next]$ ./scripts/bloat-o-meter vmlinux.org vml= inux > add/remove: 0/2 grow/shrink: 16/12 up/down: 432/-340 (92) > Function old new delta > new_slab 808 1124 +316 > its_probe_one 2860 2908 +48 ... > alloc_slab_page 284 - -284 > Total: Before=3D30534822, After=3D30534914, chg +0.00% Well considering that alloc_slab_page was marked to be "inline" as per the qualifier applied to it I would say the shrinking had an effect, but it was just enough to enable the "inline" qualifier to kick in. It could be argued that the change exposed another issue in that the alloc_slab_page function is probably large enough that it should just be "static" and not "static inline". If you can provide you config I could probably look into this further but I suspect just dropping the inline for that one function should result in net savings. The only other big change I see is in its_probe_one which I am not sure why it would be impacted since it is not passing a constant in the first place, it is passing its->numa_node. I'd be curious what the disassembly shows in terms of the change that caused it to increase in size. Otherwise the rest of the size changes seem more like code shifts than anything else likely due to the functions shifting around slightly due to a few dropping in size.