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 318E7C54F30 for ; Mon, 26 May 2025 02:23:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B0466B007B; Sun, 25 May 2025 22:23:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 460DF6B0082; Sun, 25 May 2025 22:23:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 376916B0083; Sun, 25 May 2025 22:23:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 188556B007B for ; Sun, 25 May 2025 22:23:20 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8B2A21D5506 for ; Mon, 26 May 2025 02:23:19 +0000 (UTC) X-FDA: 83483462118.29.335BAF0 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf11.hostedemail.com (Postfix) with ESMTP id CD3BA40004 for ; Mon, 26 May 2025 02:23:16 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748226197; 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=g9SqrCyVSi5RgsPSH58YLnvjFw0vwJkTVYYxRJa/DaY=; b=MRAg0wHysl0NpKgHngFYDPL44L3f97ZwpM4DdkT+atqZeWvg3z2DQEmRx3psq5ukswk99x DZl0vI80S3WjFkIwwJIYrL/AYk/O3mbwdHtqxx/itc+GC1Pj/vsPnSKsSEGBRZZXxE3JF8 14tcPS0JVAk2TFG3tl3QVYDqBKs1NYc= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748226197; a=rsa-sha256; cv=none; b=S8l9DSVw7CbOi5W42yGJ6Rcq6K230ms6U09i3Bsr3SdiEUlQicUpkWjyEfPex4n0lfPa2h S3mk8A+cmULJTbtpTYDCWD1llsA6zzqsWCaiboxEymgLW1HyUDUfwOeQ5SoCR7LwNa1o3e +9enFcnVA7aLHTv9k3WKvElPVb52Xec= X-AuditID: a67dfc5b-681ff7000002311f-27-6833d0903008 Date: Mon, 26 May 2025 11:23:07 +0900 From: Byungchul Park To: Mina Almasry Cc: willy@infradead.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, kuba@kernel.org, ilias.apalodimas@linaro.org, harry.yoo@oracle.com, hawk@kernel.org, akpm@linux-foundation.org, davem@davemloft.net, john.fastabend@gmail.com, andrew+netdev@lunn.ch, asml.silence@gmail.com, toke@redhat.com, tariqt@nvidia.com, edumazet@google.com, pabeni@redhat.com, saeedm@nvidia.com, leon@kernel.org, ast@kernel.org, daniel@iogearbox.net, david@redhat.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, horms@kernel.org, linux-rdma@vger.kernel.org, bpf@vger.kernel.org, vishal.moola@gmail.com Subject: Re: [PATCH 12/18] page_pool: use netmem APIs to access page->pp_magic in page_pool_page_is_pp() Message-ID: <20250526022307.GA27145@system.software.com> References: <20250523032609.16334-1-byungchul@sk.com> <20250523032609.16334-13-byungchul@sk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHefZe9rpcPU6rJ62khUiC5SXoFBV+qvdDkVFBFKEjX9rMqUwz VxSWg0jU7lFzyUzLeYnR8jJDJJeZVqZo6uzm0mmhVqa1vGW1SeS3H/9zDr//h8NRMiPjz6kS UwVNoiJBzkpoyWfvgtCLbZHKsLy6VWAwl7NQNpEOxQ4rA4bSKgTfJ9+IYbzhKQuFBS4KDK06 Gn6YpygYaOwTQ+/dQRpqz1VT0HehiYUc3TQFZ60mEbRV5TJwdeoOBdUZDjF0PDSw8L78NwOD thwamvUlNPTmRkGjcQm4no8gaDBXi8CVfYuFK+1GFvp1vQjaH/fRkHcmF4G5zs7A9ISBjVrF V5T0iPga/Tsxb7Qc4x+YQvgsezvFW0rPs7xl7LKYf9tVy/JNN6ZpvsY6LuJzMr+w/LeB1zT/ ta6T5c0VnTT/wtgg5sctK6PxAcnmOCFBlSZo1m2NlSgv3zCiZAdOnxjuYTNQmTQLcRzB68l0 fkAW8vLg8PXbjJtpHERM91soN7M4mNjtkx72w2tIUd0lzw6Fexny0hDvZl8cT7Jff2TdLMVA usvOe1iGSxB53hoyl/uQ5ptOeu42mMzkt1PuChQOIMWz3FwcSDIr8zyxF95NWiq2uePFeDV5 VPVUlIUkf1ve40jHaKForvIyUm+y0xeRj36eQT/PoP9v0M8zGBFdimSqxDS1QpWwfq1Sm6hK X3s4SW1Bf//m7qmZg1Y01rbHhjCH5N7SWHmkUsYo0lK0ahsiHCX3ky43hCll0jiF9oSgSYrR HEsQUmwogKPlS6URruNxMnxEkSocFYRkQfNvKuK8/DPQisFN2WFPtD4xRbVDs/qNXW9nna/U Q90bRq+H2gsKDzRi54KzURGj9mf++3aZTpX7ftihXKQ1WKMdLmvN15CM8AjHSfOvQ2Nbir9p Qv1atuzfuDNGcNYX/PSejWSSggqdV9do0nSVI5+G2fvGwNPqE7ZuSb9ueyguX7jXqz76Wp6c TlEqwkMoTYriD+mmdEMzAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRSA+e0+dh3euC6tWwbCoqShZalwolCDsFvQC6I3uFEXt+WmbWoa GZoT6aG5ih5rxtIyXzFa5raQVSraSJ1MzPWcWVlklKaJj6jcJPK/j++c8/11KEysJxZTSk0m r9XI0ySkCBdtW1cYXdYdq4ipsNFgstSTUDeRA3f67QSYahsRjE2+EsJoazsJlTfHMTC59Tj8 tExh8LFtQAi+qkEcmoptGAycf0pCiX4ag1P2agG0lLsI6G4sJeDS1G0MbPn9Quh5aCLhbf0f AgabS3BwGWtw8JUmQZt5AYw/+4qg1WITwPi5chIueswkvNf7EHhaBnC4XlCKwOL0EjA9YSKT JFxDzQsB5zC+EXJmaxZ3v1rKnfF6MM5ae5rkrD8uCLnXz5tI7unVaZxz2EcFXEnhN5Ib+fgS 5747e0mu8vOwgLM09OJch7lVuCNkv2j9YT5Nmc1rVyXIRIoLV80oo5/JmRh6QeajOvoMCqJY Jo4dulxB+BlnlrHV9zoxP5NMJOv1TgY4lFnB3nIaAjsY4yPYLpPKz/MZFXvu5SfSzzQDbF/d 6QCLmRrEPnNLZ30I67r2AZ+9jWR/3fDMNKkZDmfv/KZmdQRb+OB6QAcxO9nOhmS/DmOWso8b 2wVlaJ5xTsg4J2T8HzLOCZkRXotClZpstVyZFr9Sd0SRq1HmrDyUrraimd+oyvtlsKOxnk3N iKGQJJiWSWIVYkKerctVNyOWwiSh9BJTjEJMH5bnHue16SnarDRe14zCKVyykN6yh5eJmVR5 Jn+E5zN47b+pgApanI9OdhSE9emKH9+NoA2JVdFR2gix2HW0hTok3bx3u6YgLjOl2zWiyiu6 khzl2Bf5Y4Es9lGC+ljf8JBzdHDXtXfB7o1xX7pePfHlG07ELNqqVG44ICw6TwsTjqcuL2s7 EUxMFVkd0U8Si0OHUtZ+O9jRtS883n3WHbLGk6wq3+0tr5TgOoV8tRTT6uR/Aallo/wXAwAA X-CFilter-Loop: Reflected X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CD3BA40004 X-Stat-Signature: 6bhx5wyqugoc1qxk5ft35m6w7fe8rhfy X-Rspam-User: X-HE-Tag: 1748226196-533721 X-HE-Meta: U2FsdGVkX18JGc2euNH0FcGQ4ryCJdIeUGQ0YW5EibtJdyaNl96SeSseDT52OqCKjUwM5XJhUBwkfk8OZrLlRlR3IMdCQACYwJdB6gSA/Tn3I10gMp6x46Xgz9vkvd8gxFlQQu77bVeMWrfXEGi56rAFI8dsv/hY3d953kttPhjy3EF3e5U5qzChbJW95OB/osXEuscZEg065Mx4GLJ1i8z6DHfRI3dE0L3iu68jFCUz62EeOObZVj3ieMrlj/1uTRjwGEl0sc4/SFbd/lKhy6XPuxMIQytqknxIqjRKexI422uOX/a8ULc1+4hyQB900t+J/QIm1HZGMpkdU7LzbaUYFXbPTYWYSdmRtalxnmgdsMOp/s4rVrevY5BW+U6vnwpCYCKA7XyeD3szUQRuNrzovuN9izYobbaorjTZsDUL80oBxXb4+QyjG6jD4Zn/PdKgo27l9ButLl5XDeDcE0YqUvfR9/Hpg88jY0rFlcqodKMLwWQ9YwutE7Jk7hjIClIypVvdNmMwSZirtI4qZo1fk3+Du0tpANVIYwcmkSIyKgPIhHR9ItEAfvYu9coWZe1NmNjvO3XC+h41AGpU6+RDFsPROo0KyxlTPTm3Sc8hdy4XfYRiyIbr75ppinPbQoNouCy4XrEODMJpTGd81FrGmxr4mu7I1X47PuJ7PuZISTEX2BMQl2TFNwk8z1JW9EuBCAIUb2fIgxqQsMio7StShpSQod+JBgRr17B3gp4XdK0hSMjVad54YvzkqgO16FY17qcOUw6h5fdYWqmvHo224EUTbJwfTHuk0cPmaNfMdXaZcz/IjyeQGaQFtS32LYZngkxk5yVsNuYFysi2jH0g+3E2ZK5N4LBZBq5i/X3JusYOqAxkn9idf5+VsOFNt3xjry/SSARTUzqFF0E/NFSBgnGyluma7tJn8Mws6WlBmFOMsyiyKiPOWfxmOsZWqO5ixUJkbV3UaQuL8X1 Lf/wrOWy cuMSbOEPY0/IrIe1olA/FAy6Ui5Y7PcBIs6QG9J+i8O0OfJx8SJTyLGehgR566xoVJwiMfH1ITGfv1EhylSzyGg6Njo4vhDIIJuPcbF12GiYOmcXRoWt4d83/FVxpxwOEegJ2uap6dMNbMTCtTFAa+vtKUQ== 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, May 23, 2025 at 10:21:17AM -0700, Mina Almasry wrote: > On Thu, May 22, 2025 at 8:26 PM Byungchul Park wrote: > > > > To simplify struct page, the effort to seperate its own descriptor from > > struct page is required and the work for page pool is on going. > > > > To achieve that, all the code should avoid accessing page pool members > > of struct page directly, but use safe APIs for the purpose. > > > > Use netmem_is_pp() instead of directly accessing page->pp_magic in > > page_pool_page_is_pp(). > > > > Signed-off-by: Byungchul Park > > --- > > include/linux/mm.h | 5 +---- > > net/core/page_pool.c | 5 +++++ > > 2 files changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 8dc012e84033..3f7c80fb73ce 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -4312,10 +4312,7 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status); > > #define PP_MAGIC_MASK ~(PP_DMA_INDEX_MASK | 0x3UL) > > > > #ifdef CONFIG_PAGE_POOL > > -static inline bool page_pool_page_is_pp(struct page *page) > > -{ > > - return (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE; > > -} > > I vote for keeping this function as-is (do not convert it to netmem), > and instead modify it to access page->netmem_desc->pp_magic. Once the page pool fields are removed from struct page, struct page will have neither struct netmem_desc nor the fields.. So it's unevitable to cast it to netmem_desc in order to refer to pp_magic. Again, pp_magic is no longer associated to struct page. Thoughts? Byungchul > The reason is that page_pool_is_pp() is today only called from code > paths we have a page and not a netmem. Casting the page to a netmem > which will cast it back to a page pretty much is a waste of cpu > cycles. The page_pool is a place where we count cycles and we have > benchmarks to verify performance (I pointed you to > page_pool_bench_simple on the RFC). > > So lets avoid the cpu cycles if possible. > > -- > Thanks, > Mina