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 28991C35FF2 for ; Mon, 10 Mar 2025 15:42:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBA62280005; Mon, 10 Mar 2025 11:42:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D455F280004; Mon, 10 Mar 2025 11:42:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE3FD280005; Mon, 10 Mar 2025 11:42:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9F155280004 for ; Mon, 10 Mar 2025 11:42:35 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D307456735 for ; Mon, 10 Mar 2025 15:42:35 +0000 (UTC) X-FDA: 83206058670.30.714C0FA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id F1D8210001B for ; Mon, 10 Mar 2025 15:42:33 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uQ+mDlOS; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741621354; 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=2PwaOKrUlM1k45ynkNwJ7drq3OLEHCYNFE9EcOdF2U4=; b=SYI8o92csyGGttQn+76JjNe+R0VjHAiu2kS655iXB27TD5sDo/xcMnG4KOlTmEq07jfjjf 9aIsIMR1pFmet20DYO6PuCM/u+9ZHYOTa4c1aAYKHfkPj7QoDBga/Qzr15GRqRGkiICoXb Nn0OhS4Wrem49nw+Cc7Jv9JV4pLtLrc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741621354; a=rsa-sha256; cv=none; b=FTMRYy7WHfuqBX136Yu8Eib2ffds5kgBjjwolm8XUTqJL9N72rIRiJBkef04V979pHSEm0 rdezXDcXBBrj7ZZDgQL+g0kIBr6lGluDJFCZ0bJbDdXW2Ihes1T7NTWkUH//KhZoTZMUeY LeSGon1XYsMOboDFP3Uv6JvmYbmx18I= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uQ+mDlOS; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=2PwaOKrUlM1k45ynkNwJ7drq3OLEHCYNFE9EcOdF2U4=; b=uQ+mDlOSHJVHyLncXcWH4fDmeB i/ZkX4w+eGcPsANymWdCzEFt2UMvKqZ4cIODj91sf+hOs9zU12bxCNiGFuCKDbpDpSfHORUd+XAYs 3aEf1p6roFcMDeTGtsR2VuVFjhx048u/+zy3HiUz06TnUmUmiIXU3GnKzxNe5RHFWABXwu/vXeZXB +ezG3A1oXO9OPxdDrinHTD0ZZmKNm1MeuN6nF5+UDwYwRZduGnNX5u/C8PeOpROsmmrVa3JK8xEsB EVcDcgLbO0QcBGaeJCqMV83DQmC5lKwCoqgz6Oo4haic4p6gaL5Yg9Sy518OHJhCjxgyK3ulwnhNw kxct73vA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1trfGq-00000006bQF-3qtc; Mon, 10 Mar 2025 15:42:25 +0000 Date: Mon, 10 Mar 2025 15:42:24 +0000 From: Matthew Wilcox To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Yunsheng Lin , Andrew Morton , Jesper Dangaard Brouer , Ilias Apalodimas , "David S. Miller" , Yunsheng Lin , Yonglong Liu , Mina Almasry , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , linux-mm@kvack.org, netdev@vger.kernel.org Subject: Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and unmap them when destroying the pool Message-ID: References: <20250308145500.14046-1-toke@redhat.com> <87cyepxn7n.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87cyepxn7n.fsf@toke.dk> X-Rspam-User: X-Rspamd-Queue-Id: F1D8210001B X-Stat-Signature: du8dqxefmbh5e857ouooac966pkad6ug X-Rspamd-Server: rspam10 X-HE-Tag: 1741621353-671552 X-HE-Meta: U2FsdGVkX1+B2x9SUI8OP53D/KhLm/LDC0RlMMCA5EtL29f8q73sC/PdEFuJ2ws4hJ+0Jtt/iPfh0pEsJZ2JET238GKyNJq5+4RVo27LFhM6JPET+6sGWSScybbwz0QkOVz0GXz4RRzspwm9sS1WbhlIDh/ytJG4CFVvLZXg735v4lFTCJE9apVUsWPb0lLFcNL6UrTvHBh11AYoAuWyYigciv9sXWbzf8f1OtXuAuKrA8NW/yGlREo96nO/LYgA9Y/h9zw8O7YlmQ2auO+xsWQ5Hh1vYxjvXRBax2vIk7grPLNS/370uLjLs11jgCjrN9VYzlf8KW/17w5C/v3v6ZxD7YfuBOGdWNwxsyrtbs8Xz2PDutEaeDLcQAQw3H4EZvBo57wLM6S4T8uMMJ3ylD18hv9cAXggXp7wyZ1xEf8G8YsFRIdURvTSzVQf2oQ5gUdUbSINUZ8ryrll/x6hCYeBqemTtHfnUG0hzBmQgRNFJP0chn4/skgRIHXMEPSprgl7i5wqC+Akc1slOiqIRzornZjgsJ26o5tdvKF0ODT/iF8h8KMdZn3YqYvB42FmveLON6k78EjMFAR6k+ijO0z4YcTZCRnqzWGQevaT8o7TKN8M/MSXYZBBAM0hR2sxC5Zzxcu9yujg2k6jjQG6YNqwAzg20AGry4wWiY4phYXUQBzeWdvyN6xWB/RFF0l6C1ebDdT8iAORV+c2yKoZiTZsGUqy476T5di6oAdcSF6MRYUDcRbiqP+88krKeaYJT0DWQzWcRnBDJSZGJUCaw+5yp5Wk7nt/pCqLzP5tUXp3OlSQd7TuhI/kzZZILbCFH4r9hdKIsdR9sWXJhEZgTNu7/HbknTMvmSedbCFBGIo9oJPyPNHvdY21SxmcaXWrpUGJ7zT8yfb2MoM6mSef4ir933nOpa6wLtu2YkyKjL1J1x+dWfitvqP1JU+9IoS8Fo5hT0k/7LGnNdNKnmq oggIgB4c fhsdU23ipIHEBjTK96a4PVMrcHCpGutULh6WF/jlW4jeYoevVSq+FbB32ELn2YBPiue7F/fkrB9Z6h11lbYDv6rfbAJerFSOU4D6InfparXnqQgrwdCLq2gtOv1WGOt3CHzKSbN3LtiP7ptjPnucN9Wff4u8jIJpG2Q2UMncsXEpwcLiaDUatl0QCH0coaxjHAwYAhgza+nitTlecNMBqFkeZ5WNZ/kJYY2l5txgUZbRmBx1h7M1EPVAf6X+/vkQIYyaKOOE4GdtlaHUbI8mxZZHDFd/Dc5uqo1nhJDbvsQ1I5rSTihTgWXHms+hnkEGFpLdVgWh7wx3PMoqAr4cgDkcaJ+Gt9ckEcf5buMQQRu37Sp+Xop6bbP7NLv8MZa9PX2GU 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 Mon, Mar 10, 2025 at 10:13:32AM +0100, Toke Høiland-Jørgensen wrote: > Yunsheng Lin writes: > > Also, Using the more space in 'struct page' for the page_pool seems to > > make page_pool more coupled to the mm subsystem, which seems to not > > align with the folios work that is trying to decouple non-mm subsystem > > from the mm subsystem by avoid other subsystem using more of the 'struct > > page' as metadata from the long term point of view. > > This seems a bit theoretical; any future changes of struct page would > have to shuffle things around so we still have the ID available, > obviously :) See https://kernelnewbies.org/MatthewWilcox/Memdescs and more immediately https://kernelnewbies.org/MatthewWilcox/Memdescs/Path pagepool is going to be renamed "bump" because it's a bump allocator and "pagepool" is a nonsense name. I haven't looked into it in a lot of detail yet, but in the not-too-distant future, struct page will look like this (from your point of view): struct page { unsigned long flags; unsigned long memdesc; int _refcount; // 0 for bump union { unsigned long private; atomic_t _mapcount; // maybe used by bump? not sure }; }; 'memdesc' will be a pointer to struct bump with the bottom four bits of that pointer indicating that it's a struct bump pointer (and not, say, a folio or a slab). So if you allocate a multi-page bump, you'll get N of these pages, and they'll all point to the same struct bump where you'll maintain your actual refcount. And you'll be able to grow struct bump to your heart's content. I don't know exactly what struct bump looks like, but the core mm will have no requirements on you.