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 577B3C77B7A for ; Fri, 26 May 2023 12:47:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC7FA900002; Fri, 26 May 2023 08:47:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C78636B0075; Fri, 26 May 2023 08:47:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3FD5900002; Fri, 26 May 2023 08:47:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A59866B0074 for ; Fri, 26 May 2023 08:47:15 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5BA17ACE6E for ; Fri, 26 May 2023 12:47:15 +0000 (UTC) X-FDA: 80832381630.08.EB9B241 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 6E70040014 for ; Fri, 26 May 2023 12:47:13 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Ugl6br+/"; spf=pass (imf17.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685105233; 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=7wL75rzvxRHHweMkIElV/+uTCkQTaYtKC4NiLzMuw0M=; b=UIbIgcMDc4Fm3/6dVCqS6j6xaeY19lmN6ATwPU+/kZTAyeRA/uD74BYgMGUULYeBFbSp5u 7yFSMo9O9qJD77r1Pg+71foVyJ/Loxgd+fp08HQ5jFZw7qWfIpJel80VmPqhggnx4JZsJf qpgJDrXKUIrY624N3lpSQAuY5LVcpTo= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Ugl6br+/"; spf=pass (imf17.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685105233; a=rsa-sha256; cv=none; b=UcOax2E0zEI9zwg1zqmWbUPaF4AONv9Q5K/hPxiFvguN40UF3aNTOw6Z8YtAtnL1GmxaB7 DSHZMsGyyZJ3HHvBaiRGT5RbMMX9Dwpxophv3cGxZTnkOU/VM+kd9ULLz+t8Q2pCJsxEhq abNHzhArW0Y93BIFYYMrSBOKCk/fonw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685105232; h=from:from: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=7wL75rzvxRHHweMkIElV/+uTCkQTaYtKC4NiLzMuw0M=; b=Ugl6br+/E1Z/jYsH73KGeot/fWQKu10x/p7ow9IEiVDugK3E43nVGqk7xb44Gi/VQfUlg7 xp0T8LvJ+xuwp20gp6n9nFOKuiCJBoo1e9HIzekyxieUEuBMJYsp3LyICFVhCs8zlb8noa S0e7m5v6/ZVShQeaJKeCYtmxE6+cbgk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-657-xgCvy8lSNa2E1PbJrJo26w-1; Fri, 26 May 2023 08:47:08 -0400 X-MC-Unique: xgCvy8lSNa2E1PbJrJo26w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8F54A811E8E; Fri, 26 May 2023 12:47:06 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.39.192.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7742C8162; Fri, 26 May 2023 12:47:01 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <20230524153311.3625329-1-dhowells@redhat.com> <20230524153311.3625329-5-dhowells@redhat.com> To: Yunsheng Lin , Matthew Wilcox cc: David Howells , netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , David Ahern , Jens Axboe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, 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 , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-nvme@lists.infradead.org Subject: Re: [PATCH net-next 04/12] mm: Make the page_frag_cache allocator use multipage folios MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <739165.1685105220.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2023 13:47:00 +0100 Message-ID: <739166.1685105220@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Rspamd-Queue-Id: 6E70040014 X-Rspam-User: X-Stat-Signature: 9kxrz1nzidb43zp9kxxjfomcd8w79yd9 X-Rspamd-Server: rspam01 X-HE-Tag: 1685105233-35548 X-HE-Meta: U2FsdGVkX1/wIncBDIEeJWs/eFMsfIXr7hhVnCCaQnz6UhUsJWcSFpmlIAJxt4jVdOjS5ZfIAf5p4dim1bnJy9DuyLBiDyW1W2RvIJWYmP0+vtz9mfxgFOxqHXOvg6d244Vu65lW7Rn/VUtI0VkZA80n0Yuheu9SH7AiljPyGWfFje7GPyiC5bKjC60hGFVh3JTbiIBqeSYcT99kcBnJHVxLlPmVLoxLYKpsmPF3r0pmJyn+lB4fLoxaw3pBrdhDdJjMEZGyEieRFbKcIh6n5WPmE/tBr7Ds0QVlxFPeYIlwY12PIrGmHLmj0+dwxKaTHhIZoOlVO+Vzi6sIsQmiPjEEqvywWkogBn473saMPNT/XJES+sznXANNWHNF9nBbcfvn+GqOBRTd2pwRVNxwm+zeldtfBofJyVN5bG4zbmRd8YwSfcqFUi7hKbcyuXS17kOK5+WK1vHTOXOzf3tjlx6NgKPaLuCPRWydDKcwkojHOGlYnBv/KVpKLMKnQGwSlUMVL21xomLdbWaO8P9xySA41mk91u2E926G485t69utcpdkKWuuAxDQ9GcMem+6ogtjXuBrMqMckskbRdxTU7oij0jPadiQm9zPFCJY8OYXcqt6Lo2MR7mw53LblcE34Vg+QntTd94JDq9yzLeSJM8XpZZkNPPDr3zw7QQF8kBGTkJVuezV65HDzI18MOL6VbDf1jckROiAA4T5fdM/5YNMirAVEcdK431nWI5abQFC9Erj/sX0OyMb13zlLQ9B70AWft7vnei3XGWmoOwYDIw7RvolhxCAV9SIKtDYp3gTDioQjagwBK2ePFfY8CBpFumg9bMoeYeWOvDv0UlJzK+kfBG1eVJ9y6geryjBVzBe3QhdTjJhlqrKH23YRSlSZYxI8wWo4gCCBf+bm03BblnBueaRKYibYjZvuu6LvyLgGg2Lds9oMp3T3JiusEHbXEHLnVSgf/WMe1IQKL5 U+yg0Sc9 keIogx8SDRR8VXAfcFjmUM+cKV8FLaT7rVlSjUEXyiTEl2fQza1NlBWYtMtSnPx6VVyu9KMTIWz8BoWUzAdtpAPlO/ndfOIHlpQOGpYOAiiGXUdVG4JEdrDAtJcUXF2yYtiivaj2NFnlOdF9KlCfg9JEd/YGBUX3yEYWZXomYKjqlXzTEdM/fLvOaJU5kldH5IlfJannd/zPs7Ddj56Nfkt5zTb34OFuFDSWJt31PuOHEcT+KSodIs0bAG9A9sxEqtomzKNT3VcUnRP4run9qmPZ6X05QzkP+Ck+K919u1f161ok= 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: Yunsheng Lin wrote: > > Change the page_frag_cache allocator to use multipage folios rather th= an > > groups of pages. This reduces page_frag_free to just a folio_put() or > > put_page(). > = > put_page() is not used in this patch, perhaps remove it to avoid > the confusion? Will do if I need to respin the patches. > Also, Is there any significant difference between __free_pages() > and folio_put()? IOW, what does the 'reduces' part means here? I meant that the folio code handles page compounding for us and we don't n= eed to work out how big the page is for ourselves. If you look at __free_pages(), you can see a PageHead() call. folio_put() doesn't need that. > 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? There is a benefit: a folio pointer always points to the head page and so = we never need to do "is this compound? where's the head?" logic to find it. = When going from a page pointer, we still have to find the head. Ultimately, the aim is to reduce struct page to a typed pointer to massive= ly reduce the amount of space consumed by mem_map[]. A page struct will then point at a folio or a slab struct or one of a number of different types. = But to get to that point, we have to stop a whole lot of things from using pag= e structs, but rather use some other type, such as folio. Eventually, there won't be a need for head pages and tail pages per se - j= ust memory objects of different sizes. > > 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 fol= io *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 pa= tch? Hmmm... fair point, though va is calculated from the page pointer on most arches without the need to dereference struct page (only arc, m68k and spa= rc define WANT_PAGE_VIRTUAL). David