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 83423C3DA5D for ; Sun, 21 Jul 2024 21:41:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 795766B0082; Sun, 21 Jul 2024 17:41:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 745426B0085; Sun, 21 Jul 2024 17:41:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60CCF6B0088; Sun, 21 Jul 2024 17:41:40 -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 43C2B6B0082 for ; Sun, 21 Jul 2024 17:41:40 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AEC9714132B for ; Sun, 21 Jul 2024 21:41:39 +0000 (UTC) X-FDA: 82365081918.03.CCFF1F6 Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by imf11.hostedemail.com (Postfix) with ESMTP id DA15240005 for ; Sun, 21 Jul 2024 21:41:37 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=giRiHnkg; spf=pass (imf11.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.166.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=1721598053; 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=0nJBFOve/nzOSIc3tl9SNeSNgkEB09v1kPl4DmpsSPc=; b=iE9sqrAOyzCf7ZJHQ39zxtD5d09SaBDZeZzO0PE2UmofEckx9Nw8yp2KFbiGne1Bjsb4Wa qO/cM7x5esYcJLwXSoNzKQHeMaPueYDS94a7MURRyBFfnaA6YW+GUWSKZF5VMpCh7MbW1r Xu1H9hEjojLdTltnXGqyTD88lXYNh08= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721598053; a=rsa-sha256; cv=none; b=zEnzYxbwrO1e1sHuVQpdiEjj6pIlBpM7b2VBVIRVA5ih7dXQF3yai7lFUisRZw5+ANIJYA Bi70jKu/7KML3EXPbjZ3SEjJiInGHIH+//bSZLmpizgX0zGhhUTFnyicewdCopkvXgmoCn P8K/9mvFfniSuVWWgo9uj7PbIQjqFPw= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=giRiHnkg; spf=pass (imf11.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.166.180 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-il1-f180.google.com with SMTP id e9e14a558f8ab-39641271f2aso13575605ab.3 for ; Sun, 21 Jul 2024 14:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721598097; x=1722202897; 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=0nJBFOve/nzOSIc3tl9SNeSNgkEB09v1kPl4DmpsSPc=; b=giRiHnkgkBpG13u1SIZZQDTmYyB1ygZRk3eVaMF1gEhUjCZsZauEu6p4Q1nAFomea5 IHYfEzHhQzbBTfaOmZkgeAQxuH8x79iq0WEzvV8bpQSmNeAgFUbOLvGAu5zzAddt3kjk Kvkb/bo7V0vwXLiMBBf0qXKi8eL25UXhFfCc2E3KHwALEiWoROB8AwtIRihLuPcyCUYC GwW4RkQWC2uQ3SUYDYKYgh7qFbY34TlCR/wayBHTJGSU5lCOz3KDyu7SiX1c2V3OjbkE kmQudf7GmTNsVBZO7gQEpYYksnBDrU/hVdkK42WHrlMlXn4nq+cgO/ZTGAqvy3P9fYND fplw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721598097; x=1722202897; 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=0nJBFOve/nzOSIc3tl9SNeSNgkEB09v1kPl4DmpsSPc=; b=l/DfxNZ57mezYQMhTEzpskCFnftuqYjxfHzVj+rNG76pXM4qvgUcaOvyn3uHWRjV42 BXkoONhMu7qerOvgmcmzja8QVmYNpt7/I0/TqnIDtLfUNaOJP7FqryDAwxFwWkDB3Z9u VjSTOu3VBYRefOkayl1mvBEXNQNkIsFIwrO9aXu5pqWHOHpXEzXVzu+eXZnyYqAe9IAZ qEmnsiizhZSMAYwnIag5F6lS6cKL6J4c4Kcbiketb3EcJewycbSWvTzgWlZeo36IbNKR /xSD5T/qR0Y2KLt3UFI+EAWspT3lsEezLprPE7KwMC/uC6nqziSl7HSx+rGlsXUSskM6 HE2A== X-Forwarded-Encrypted: i=1; AJvYcCVNPYHk5foNn+utbissI+yvddu8cJO49AJXV0njHNnBQyR2nYwPJ/HxKiBtq6fJeBrA7uJsbSBdPQbwdIMpXoA6Puw= X-Gm-Message-State: AOJu0YywqrNLYAoaNjmfrOwgUx6Zwal2m0kw5TaSVhbqB/HNXb8n4bhQ 6008wPSYT/tXK9iVVzy+J+cHBloDUho8b6jBhcbkKe3RKThRAmXB X-Google-Smtp-Source: AGHT+IFPCrRoqgoOPxRC6ckPS8S/2QD5STC1qy8/ICCKYIJOKNY6tmwsfglePPXXZ9/QaoHcg71MmQ== X-Received: by 2002:a05:6e02:1a88:b0:374:9916:92 with SMTP id e9e14a558f8ab-399403db700mr59896895ab.22.1721598096853; Sun, 21 Jul 2024 14:41:36 -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 d9443c01a7336-1fd6f44e96csm40855585ad.216.2024.07.21.14.41.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jul 2024 14:41:36 -0700 (PDT) Message-ID: Subject: Re: [RFC v11 09/14] mm: page_frag: use __alloc_pages() to replace alloc_pages_node() From: Alexander H Duyck To: Yunsheng Lin , davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Date: Sun, 21 Jul 2024 14:41:34 -0700 In-Reply-To: <20240719093338.55117-10-linyunsheng@huawei.com> References: <20240719093338.55117-1-linyunsheng@huawei.com> <20240719093338.55117-10-linyunsheng@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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DA15240005 X-Stat-Signature: 9r1j4uzyr35c1mu9ddnumdd1ej7cze7r X-HE-Tag: 1721598097-29236 X-HE-Meta: U2FsdGVkX1/oaboEc1E8VvLp5+1+EdnuEX6JSRK8Ak8HJ2RKDfOXY3PsGqX4Ny2RZlkHqHzwdYhofGWxzaaV2cABtX8WpzvuS1ilTmukuNsx9JJNDZFLv2bqVR7nmioBto2vQQ1XNvThHCHZzh1KbPl6+sDxYIoZO+drvADbcErFkZSddicJo0wpF0OQrgOejSjZj3o6j782nJXKB3EVdmH4Pz3u3XJ4PXSnt2IKqiEBKIPiUYanmjAwUt8yosL4QlwArTsI4Fp5lsosFHXJgj3NeMegpPpymzFB6DXKTHp+0ShZDHXR4mKnMC7q9VC+hXFj+YebIXlwzRfJHsObWlMqfAzQZ09kF/zuTMtIME8ESotKBMfcSuBRAQtotZm8FsF0d2cx3WwSwq+Et61LmPl5G1K0m3zV2APgX6MyE9pesoGGWJjvPcCtcK7+09RxgEZMoe9qAOxebBMPbd8HKqYciidD+eRdJSa3rf+5jkfbNL7Jtdhue4WyHAVUFRNmVDopnIvOTCY6K7s/QHpquLcppvEQlc2BH1iDcbrxd0+cw2cbgIPoKwNBfrKBiRRlzapJcZVkpTV2ZB6ev4CHDLL0Wk4mZKFG13WeCilewopZRxn0TljFZr8CgJ61oWW5zCBjj0L0eTLCslIaqAi4q+kK1PbCovgwcK3tb7ToBLE6lS0XDlTPUQyn6pbDhadnbJpTwTpcGL885AT2Kflg+QNEsMeiHzKW5Dq2a1RFyOXT8ROjvmOUcuSy4tC/4Vow1Q5RZa3noNxp9J5j+HojuY9xcas5GwIxaw+SvAdrunpOAfra4j1HbDfIMIR7knCeB1s+ouWJEP0Hygg26qFcB2Lu9aEBLiW7BZCLnv/wd88Nc8PbOBF7uzZuyV2ckjxyS45bgppPcwcY2TUYfHPBcoTmGT9PWDt7ipzhzSO/Rzrz3EYPkgUFfFxOLFe2/xWykN3BFa6JHoHTXsLv/UM bjNtes6K SaYin+TYPwnr3omHQGOxjZKhlnjHkRDdGyGVN9kkJcuk9YW0Z31pr3Qjx1+bnt3l55d6iPjZ5ZUz+U8pEv7vtwDUXd0cryXhGVFNK5krGakEnWNyXeZ/p9vvpfWTQUmxK3gKdw748n9CbXJsup0X15x1PlqJ6ZoOrmtDGZonON97n2XLw2a6m8AjuhJk80ZrKK4e6iHlnZ2mk/dfLHBl25qp3osuAoCr8ZPy7zqEi9Nx2cbftVTbmWjj51D83MipEGVbSkKGGALJbeSld5hhtaqMWWB+u9brgNlX2QKlcGpyc+ONB851kBwQ8sbY06j2sf8GmcHPSptREqggnerc2OcEYc9FnDDZlpST4IckSKip6lJ+5zCNkfJThW/r3F6uc1Dq+OyW4ha08eOGwKeCHUzPlbOg8CSWuvVtZuNoolLWeZbKgCtgHUI8p1c1wGROg7CiH 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 Fri, 2024-07-19 at 17:33 +0800, Yunsheng Lin wrote: > There are more new APIs calling __page_frag_cache_refill() in > this patchset, which may cause compiler not being able to inline > __page_frag_cache_refill() into __page_frag_alloc_va_align(). >=20 > Not being able to do the inlining seems to casue some notiable > performance degradation in arm64 system with 64K PAGE_SIZE after > adding new API calling __page_frag_cache_refill(). >=20 > It seems there is about 24Bytes binary size increase for > __page_frag_cache_refill() and __page_frag_cache_refill() 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 still part of the mm > system. >=20 > CC: Alexander Duyck > Signed-off-by: Yunsheng Lin > --- > mm/page_frag_cache.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >=20 > diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c > index d9c9cad17af7..3f162e9d23ba 100644 > --- a/mm/page_frag_cache.c > +++ b/mm/page_frag_cache.c > @@ -59,11 +59,11 @@ static struct page *__page_frag_cache_refill(struct p= age_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)) { > 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 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.