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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 EC324C433ED for ; Thu, 13 May 2021 02:37:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5CD07613FE for ; Thu, 13 May 2021 02:37:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CD07613FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF5806B0036; Wed, 12 May 2021 22:37:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACC676B006E; Wed, 12 May 2021 22:37:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96C0E6B0070; Wed, 12 May 2021 22:37:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id 69F1A6B0036 for ; Wed, 12 May 2021 22:37:35 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EC6E3181AF5D0 for ; Thu, 13 May 2021 02:37:34 +0000 (UTC) X-FDA: 78134646828.33.0F99528 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id AF991500152B for ; Thu, 13 May 2021 02:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=TenrWiIkYtVAh+YSG9ppJcEvQ+ICO0xNa6eESJHAhgA=; b=oY3n65PbfkVv41I70t6lqq9DW7 Nc49YFeX1YsxjnKc0EHtgpu4GUOsOwCB4Bh/AhPUTFuUZe5ZZ23q++8CBxNxQ/SJwzyxVqsccpHxl Vss0GOdtaPNnC5HQvhuiBrMv/ZyXU1Cn1UCgS1RqKmE4JumRPEArf0t8OfD01+5KetSMt25D9C6So gkURYhk+BRL3RNHclDOJbCSiqhC6yp82vfs6onbn8EfZFgPcmpcpSnwSUPKfKZkQvS54ISzuWSkvP 2nyFXSKgI+RE0q+lu9vHxXIzurzEOYVFSDhGIWg/1Ld4oWEChi48USDfO7D135gwPtJNdpOAO4tTK O1V2RKqg==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lh1Bw-0097Bt-GN; Thu, 13 May 2021 02:35:24 +0000 Date: Thu, 13 May 2021 03:35:12 +0100 From: Matthew Wilcox To: Yunsheng Lin Cc: Ilias Apalodimas , Matteo Croce , Networking , Linux-MM , Ayush Sawal , Vinay Kumar Yadav , Rohit Maheshwari , "David S. Miller" , Jakub Kicinski , Thomas Petazzoni , Marcin Wojtas , Russell King , Mirko Lindner , Stephen Hemminger , Tariq Toukan , Jesper Dangaard Brouer , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Boris Pismenny , Arnd Bergmann , Andrew Morton , "Peter Zijlstra (Intel)" , Vlastimil Babka , Yu Zhao , Will Deacon , Michel Lespinasse , Fenghua Yu , Roman Gushchin , Hugh Dickins , Peter Xu , Jason Gunthorpe , Jonathan Lemon , Alexander Lobakin , Cong Wang , wenxu , Kevin Hao , Jakub Sitnicki , Marco Elver , Willem de Bruijn , Miaohe Lin , Guillaume Nault , open list , linux-rdma@vger.kernel.org, bpf , Eric Dumazet , David Ahern , Lorenzo Bianconi , Saeed Mahameed , Andrew Lunn , Paolo Abeni , Sven Auhagen Subject: Re: [PATCH net-next v4 1/4] mm: add a signature in struct page Message-ID: References: <20210511133118.15012-1-mcroce@linux.microsoft.com> <20210511133118.15012-2-mcroce@linux.microsoft.com> <3f9a0fb0-9cb9-686d-e89b-ea589d88ab58@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f9a0fb0-9cb9-686d-e89b-ea589d88ab58@huawei.com> Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oY3n65Pb; dmarc=none; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: 7i1j17usc8jqmmtwkxsbuggsh13jdgct X-Rspamd-Queue-Id: AF991500152B X-Rspamd-Server: rspam02 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620873450-853429 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: On Thu, May 13, 2021 at 10:15:26AM +0800, Yunsheng Lin wrote: > On 2021/5/12 23:57, Matthew Wilcox wrote: > > You'll need something like this because of the current use of > > page->index to mean "pfmemalloc". > > > > @@ -1682,12 +1684,12 @@ static inline bool page_is_pfmemalloc(const struct page *page) > > */ > > static inline void set_page_pfmemalloc(struct page *page) > > { > > - page->index = -1UL; > > + page->compound_head = 2; > > Is there any reason why not use "page->compound_head |= 2"? as > corresponding to the "page->compound_head & 2" in the above > page_is_pfmemalloc()? > > Also, this may mean we need to make sure to pass head page or > base page to set_page_pfmemalloc() if using > "page->compound_head = 2", because it clears the bit 0 and head > page ptr for tail page too, right? I think what you're missing here is that this page is freshly allocated. This is information being passed from the page allocator to any user who cares to look at it. By definition, it's set on the head/base page, and there is nothing else present in the page->compound_head. Doing an OR is more expensive than just setting it to 2. I'm not really sure why set/clear page_pfmemalloc are defined in mm.h. They should probably be in mm/page_alloc.c where nobody else would ever think that they could or should be calling them. > > struct { /* page_pool used by netstack */ > > - /** > > - * @dma_addr: might require a 64-bit value on > > - * 32-bit architectures. > > - */ > > + unsigned long pp_magic; > > + struct page_pool *pp; > > + unsigned long _pp_mapping_pad; > > unsigned long dma_addr[2]; > > It seems the dma_addr[1] aliases with page->private, and > page_private() is used in skb_copy_ubufs()? > > It seems we can avoid using page_private() in skb_copy_ubufs() > by using a dynamic allocated array to store the page ptr? This is why I hate it when people use page_private() instead of documenting what they're doing in struct page. There is no way to know (as an outsider to networking) whether the page in skb_copy_ubufs() comes from page_pool. I looked at it, and thought it didn't: page = alloc_page(gfp_mask); but if you say those pages can come from page_pool, I believe you.