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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99225C7EE23 for ; Fri, 26 May 2023 11:56:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231613AbjEZL4V (ORCPT ); Fri, 26 May 2023 07:56:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231440AbjEZL4O (ORCPT ); Fri, 26 May 2023 07:56:14 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3669116; Fri, 26 May 2023 04:56:12 -0700 (PDT) Received: from dggpemm500005.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4QSNYk2f5Tz18LY9; Fri, 26 May 2023 19:51:38 +0800 (CST) Received: from [10.69.30.204] (10.69.30.204) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 26 May 2023 19:56:10 +0800 Subject: Re: [PATCH net-next 04/12] mm: Make the page_frag_cache allocator use multipage folios To: David Howells , CC: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , David Ahern , Matthew Wilcox , Jens Axboe , , , Jeroen de Borst , Catherine Sullivan , Shailend Chand , Felix Fietkau , John Crispin , Sean Wang , Mark Lee , Lorenzo Bianconi , Matthias Brugger , AngeloGioacchino Del Regno , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Chaitanya Kulkarni , Andrew Morton , , , References: <20230524153311.3625329-1-dhowells@redhat.com> <20230524153311.3625329-5-dhowells@redhat.com> From: Yunsheng Lin Message-ID: Date: Fri, 26 May 2023 19:56:09 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20230524153311.3625329-5-dhowells@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/5/24 23:33, David Howells wrote: > Change the page_frag_cache allocator to use multipage folios rather than > groups of pages. This reduces page_frag_free to just a folio_put() or > put_page(). Hi, David put_page() is not used in this patch, perhaps remove it to avoid the confusion? Also, Is there any significant difference between __free_pages() and folio_put()? IOW, what does the 'reduces' part means here? I followed some disscusion about folio before, but have not really understood about real difference between 'multipage folios' and 'groups of pages' yet. Is folio mostly used to avoid the confusion about whether a page is 'headpage of compound page', 'base page' or 'tailpage of compound page'? Or is there any abvious benefit about folio that I missed? > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 306a3d1a0fa6..d7c52a5979cc 100644 > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -420,18 +420,13 @@ static inline void *folio_get_private(struct folio *folio) > } > > struct page_frag_cache { > - void * va; > -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > - __u16 offset; > - __u16 size; > -#else > - __u32 offset; > -#endif > + struct folio *folio; > + unsigned int offset; > /* we maintain a pagecount bias, so that we dont dirty cache line > * containing page->_refcount every time we allocate a fragment. > */ > - unsigned int pagecnt_bias; > - bool pfmemalloc; > + unsigned int pagecnt_bias; > + bool pfmemalloc; > }; It seems 'va' and 'size' field is used to avoid touching 'stuct page' to avoid possible cache bouncing when there is more frag can be allocated from the page while other frags is freed at the same time before this patch? It might be worth calling that out in the commit log or split it into another patch to make it clearer and easier to review?