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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A858C433DB for ; Sun, 31 Jan 2021 15:37:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6A3C164E4E for ; Sun, 31 Jan 2021 15:37:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232058AbhAaPg4 (ORCPT ); Sun, 31 Jan 2021 10:36:56 -0500 Received: from mail1.protonmail.ch ([185.70.40.18]:62432 "EHLO mail1.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232252AbhAaM6Q (ORCPT ); Sun, 31 Jan 2021 07:58:16 -0500 Date: Sun, 31 Jan 2021 12:57:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail; t=1612097850; bh=hy3HTU1Gr4SJ412CK0eDCO6whxGXOGwlEZQ/bHzh0IY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=gOF3DQLDOPbnITXBUL2KPwaqec06jg7hgwxBrpixduvxzEnKNGsfv8ItuXKrxv9Ng JiqbWegAiSb0RANpw00MRZt5dHVkVaU/4aT5yLL76tDfJs1aAdwYldD7IWkRc5kxbh 1BAJMWanlZQ2JqPkXy6HSIYWPNKbrH0EQAF1HDdchGDHYnALdR6ajs+2btoq67GU9f f5YZ1517Lx6mBTrwwu58TBCcS9IuiaspQ6k7jtFh66w62CLwSumleX42KAPMkjKfzH bHZna372czPrByZznTmm5VyRMiP9VCQ0UQEj/5CLGRQO8Ef03IeNcCrs59678BmNjl NGoTfgARWpgvw== To: Matthew Wilcox From: Alexander Lobakin Cc: Alexander Lobakin , "David S. Miller" , Jakub Kicinski , John Hubbard , David Rientjes , Yisen Zhuang , Salil Mehta , Jesse Brandeburg , Tony Nguyen , Saeed Mahameed , Leon Romanovsky , Andrew Morton , Jesper Dangaard Brouer , Ilias Apalodimas , Jonathan Lemon , Willem de Bruijn , Randy Dunlap , Pablo Neira Ayuso , Dexuan Cui , Jakub Sitnicki , Marco Elver , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org, linux-mm@kvack.org Reply-To: Alexander Lobakin Subject: Re: [PATCH v3 net-next 3/5] net: introduce common dev_page_is_reusable() Message-ID: <20210131125713.8710-1-alobakin@pm.me> In-Reply-To: <20210131122205.GL308988@casper.infradead.org> References: <20210131120844.7529-1-alobakin@pm.me> <20210131120844.7529-4-alobakin@pm.me> <20210131122205.GL308988@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org From: Matthew Wilcox Date: Sun, 31 Jan 2021 12:22:05 +0000 > On Sun, Jan 31, 2021 at 12:11:52PM +0000, Alexander Lobakin wrote: > > A bunch of drivers test the page before reusing/recycling for two > > common conditions: > > - if a page was allocated under memory pressure (pfmemalloc page); > > - if a page was allocated at a distant memory node (to exclude > > slowdowns). > > > > Introduce a new common inline for doing this, with likely() already > > folded inside to make driver code a bit simpler. >=20 > I don't see the need for the 'dev_' prefix. That actually confuses me > because it makes me think this is tied to ZONE_DEVICE or some such. Several functions right above this one also use 'dev_' prefix. It's a rather old mark that it's about network devices. > So how about calling it just 'page_is_reusable' and putting it in mm.h > with page_is_pfmemalloc() and making the comment a little less network-ce= ntric? This pair of conditions (!pfmemalloc + local memory node) is really specific to network drivers. I didn't see any other instances of such tests, so I don't see a reason to place it in a more common mm.h. > Or call it something like skb_page_is_recyclable() since it's only used > by networking today. But I bet it could/should be used more widely. There's nothing about skb. Tested page is just a memory chunk for DMA transaction. It can be used as skb head/frag, for XDP buffer/frame or for XSK umem. > > +/** > > + * dev_page_is_reusable - check whether a page can be reused for netwo= rk Rx > > + * @page: the page to test > > + * > > + * A page shouldn't be considered for reusing/recycling if it was allo= cated > > + * under memory pressure or at a distant memory node. > > + * > > + * Returns false if this page should be returned to page allocator, tr= ue > > + * otherwise. > > + */ > > +static inline bool dev_page_is_reusable(const struct page *page) > > +{ > > +=09return likely(page_to_nid(page) =3D=3D numa_mem_id() && > > +=09=09 !page_is_pfmemalloc(page)); > > +} > > + Al From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Lobakin Date: Sun, 31 Jan 2021 12:57:29 +0000 Subject: [Intel-wired-lan] [PATCH v3 net-next 3/5] net: introduce common dev_page_is_reusable() In-Reply-To: <20210131122205.GL308988@casper.infradead.org> References: <20210131120844.7529-1-alobakin@pm.me> <20210131120844.7529-4-alobakin@pm.me> <20210131122205.GL308988@casper.infradead.org> Message-ID: <20210131125713.8710-1-alobakin@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: From: Matthew Wilcox Date: Sun, 31 Jan 2021 12:22:05 +0000 > On Sun, Jan 31, 2021 at 12:11:52PM +0000, Alexander Lobakin wrote: > > A bunch of drivers test the page before reusing/recycling for two > > common conditions: > > - if a page was allocated under memory pressure (pfmemalloc page); > > - if a page was allocated at a distant memory node (to exclude > > slowdowns). > > > > Introduce a new common inline for doing this, with likely() already > > folded inside to make driver code a bit simpler. > > I don't see the need for the 'dev_' prefix. That actually confuses me > because it makes me think this is tied to ZONE_DEVICE or some such. Several functions right above this one also use 'dev_' prefix. It's a rather old mark that it's about network devices. > So how about calling it just 'page_is_reusable' and putting it in mm.h > with page_is_pfmemalloc() and making the comment a little less network-centric? This pair of conditions (!pfmemalloc + local memory node) is really specific to network drivers. I didn't see any other instances of such tests, so I don't see a reason to place it in a more common mm.h. > Or call it something like skb_page_is_recyclable() since it's only used > by networking today. But I bet it could/should be used more widely. There's nothing about skb. Tested page is just a memory chunk for DMA transaction. It can be used as skb head/frag, for XDP buffer/frame or for XSK umem. > > +/** > > + * dev_page_is_reusable - check whether a page can be reused for network Rx > > + * @page: the page to test > > + * > > + * A page shouldn't be considered for reusing/recycling if it was allocated > > + * under memory pressure or at a distant memory node. > > + * > > + * Returns false if this page should be returned to page allocator, true > > + * otherwise. > > + */ > > +static inline bool dev_page_is_reusable(const struct page *page) > > +{ > > + return likely(page_to_nid(page) == numa_mem_id() && > > + !page_is_pfmemalloc(page)); > > +} > > + Al