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 2070DC282DE for ; Mon, 10 Mar 2025 22:00:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEFE9280005; Mon, 10 Mar 2025 18:00:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D77F9280004; Mon, 10 Mar 2025 18:00:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF2A2280005; Mon, 10 Mar 2025 18:00:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9CF3F280004 for ; Mon, 10 Mar 2025 18:00:36 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 69D8B1615EE for ; Mon, 10 Mar 2025 22:00:38 +0000 (UTC) X-FDA: 83207011356.09.5122CD8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 334AC40012 for ; Mon, 10 Mar 2025 22:00:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SToYAf7G; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741644036; a=rsa-sha256; cv=none; b=GEwsvi9G+ECsOYmjEyAlQ2uN148l+vdU8j0uEtjb4lrNlWckMBQQ/WVR0LS7qZXDUsvIe5 BaZ+y97oLDUH2WLEjmdBBem//BtFZ+SmOAW1d0T4Vm6AN5q7vceSkkcsfL8DM22gy2PfhC Uzdfj8VJwXAaCNfRhjJqT/Lvts0VFso= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SToYAf7G; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741644036; 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=Zg0Ld06rImD10upuQRDbFwN4znvACEkA/1Fmsd4u9Mk=; b=SsxVB+V7Ikfq1CEfKD+gkRaGEolYakxG/Xubbasdu/9sqVb++qKap5qa6nVT4d8GtVaZNA 2wN4dGxC9EBqGP3Ya6EXI/yuSPaOwS8d3jDkxywPrYr5PghXb/r0HaKJM045WatxPfK7w2 h34Ugn05O4QuhMbbgxI+1g/KTczj7qQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741644034; 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=Zg0Ld06rImD10upuQRDbFwN4znvACEkA/1Fmsd4u9Mk=; b=SToYAf7GWFPieUeE+eiL0W4C6t5FsLHHjX0o8CTmvHcLEyou9FSPLm/fr/wWEr4r7wOwh6 bipsTNoaFOmmlTnz83/ob6SiZRcB1jyInn96egdWoYZnmns2U1gaRcV1MG5NcCXrY/B7hZ 0aRAq5aH/86BUVAQFZaNdNS2P8VBWNI= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-619-X0lD4LbaMrabMiR6j1sDEg-1; Mon, 10 Mar 2025 18:00:29 -0400 X-MC-Unique: X0lD4LbaMrabMiR6j1sDEg-1 X-Mimecast-MFC-AGG-ID: X0lD4LbaMrabMiR6j1sDEg_1741644028 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-54994e431dcso1585481e87.0 for ; Mon, 10 Mar 2025 15:00:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741644028; x=1742248828; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3CJdPnowOI8YmDQ3h17VXbzQRRXbDksv4PPsyAowEwY=; b=pp81ggcVRSy7LNMg9z0XgbCY29EtiTl2pcH5CvjaPHdem+H9UvF7LeYuG6dp/S9/AJ 5LlKRqmbQ2zXVaIZwAsSxZc4ku9qe31iIflMRME5Uwkp+sKPmKy6KmkscP2VwRqOCvlj FlxDyNkNKitRb0b0VFQYzBxRR+HeHBBYpookpz3evG3waM33dk5AaoHcgk7iWye+J/A/ nOBjIABI/1C2dYbctiFIP2LrgctIGePpfnP9C+29aFyrcoAkpmQSpa5SQmnu2FpOByKX 1iiyD3tTcTZGnHKm/8qrb3y3rpswfJK2fY5r63RA+twCUsKB5cEGO3rm4OgKOkyhSvFu Rzyw== X-Forwarded-Encrypted: i=1; AJvYcCUPv+VqlCHrCfor/Y8v5z8oetvM4ITeKO4rB7YW+1qp2U2lTn8UmFp6Rnl23ORHbLPkU3QeGcUc3Q==@kvack.org X-Gm-Message-State: AOJu0YxggfAqVJlbo7dB3U/YX29o4NLO/Y2TqWa5nzfH3/BhIpgnV0ZL L773vM/PxnQLQZSyKCLLdt8kfSShqV5q/KLyUZ86VC/QXCps3tyITJi8Xar9pMI8jOQYDXxyBJt fwi8ekINF3ckk6qzsqfjuwY149p9rihIF8dJ47MRNq34BQ58i X-Gm-Gg: ASbGncshZiifnUtZ8lTEdaqERqXnlQdUmrzB0OAoeaEpYdPcE7X5e/UZxgepTF5D41+ TPkk2IAfygA09aujm2N2+6dROiTvibjO9Vj4498frEncQB0d4jbYELepZNBOObiBnIAOzqzxApz Upf7cEGHF3CY8ZFGfBrCAQ/0c8f+NSBJWk9pydSkeBPbFuc/z/v7Z3E7Tl+fKuXhnnQgB5z/O3h K4rmCua+DM+U4t/AKzOunHSStga3dstPIr71Nnhnc+aCQTDHG1aNrfDR0EJ86QaiOOhjc74MEks rJDlamcOatdU X-Received: by 2002:ac2:53a3:0:b0:545:2eca:863 with SMTP id 2adb3069b0e04-54990ead1d8mr3414196e87.42.1741644027971; Mon, 10 Mar 2025 15:00:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHdNFgxOeNZOtS3nG+6oUcuZqBKM4a065DiazuwBgTZj10ngA0NBSWFQ9NBrJuqyh5TY5tRCA== X-Received: by 2002:ac2:53a3:0:b0:545:2eca:863 with SMTP id 2adb3069b0e04-54990ead1d8mr3414184e87.42.1741644027545; Mon, 10 Mar 2025 15:00:27 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5498b0bd032sm1593817e87.142.2025.03.10.15.00.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Mar 2025 15:00:26 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 871DA18FA3F0; Mon, 10 Mar 2025 18:26:24 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Matthew Wilcox 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 In-Reply-To: References: <20250308145500.14046-1-toke@redhat.com> <87cyepxn7n.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 10 Mar 2025 18:26:23 +0100 Message-ID: <87v7sgkda8.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: U9GRMWtZCxKhlzcCUm3SU_oJMdiB946kSNk6kOB_lco_1741644028 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 334AC40012 X-Rspamd-Server: rspam11 X-Stat-Signature: 49xednxybu5qaxyrwrtuung5sm8joyq5 X-Rspam-User: X-HE-Tag: 1741644034-145597 X-HE-Meta: U2FsdGVkX19Htk0CQjow1qVWRBjKyHz0AeuffUNxjHWB6kz+ITkxEoc7TozJwAZJiYBSbkaYJi0VhLyoL4HBJve4A9lhyWhHyrS/7v7i6Cabh52PDVqpflCwxS+3YMFW3BXOfNya4PnqWRuPfxpYcu703C3aSATFYlvnwVyB1nMvkPismbGN5bJRtqkKIR/BEsJ4jUvh05x0xW+2BRUD2D+ZUdofhaf3z7+brbZEEU/2DH1ClV4L3vkugXBPUK8YJkN7QPCoM8blQrUjogQlwoIsWL9+Wxxn7zuhjNa/EsKoe3GL6cyB1oNSk2B6J/HNpXgb9tmhRE17b9hXqXGn3LtDLj3WUKW11NKqcor97gy3YQ6MZgtNe5H7yoYYboDWyuSO7oJlDHyTXpKF0eglKNAwsAcrhVFLlhw1uX8ji8R7gjD+F6g32dkM6Frq59KEP4fQmyuqSeeX5gHZysDo60EImfQW8pg8MnN952HbtEXxl5J6e3XEDz1CU/BBRjARI0IWuxheMA+yCTr83H2bYQZ0YWDQz0Kb/cY21YBIY462oG7OKW50WgWA2fPimBNWOdjvIC9cwun1iVpQRAs7qHm4TGbdCfE055bTL3zGTylH4Dadk6r7czbMuLSFmejZsS7xXu7R4vZk90ZL9RewNSKEhJKeGOx8jQ9NBSjyEAp7nICgukurI1RN+E8sdDX16nkbc76oZldr+MnuTUMaMfWXK2qauduUcU8Uv+obOsyIilvzVRO/d3sAktUXpXcxvUfePYUK3VISLhNt9Ha4rEHEYcRFeN/cz7VJKGWolR0O7rP2hoDcRJRPhZMfs0pojz9FZWnAkDXQCCLP4cK3yHUZLDUdwgMX5RkLoIz+uJ63ek67oUzPexCCq0TpEr7PY5O0k8Zb71Y9riJhOyYKt4iV9wNEmvYlpgwDDkjky0J+Hlaqp/GvF8X0qeVKMV3gmUS1UIc8nrgP78GOeDC Osv+4eLI ggYApQBN4kGsdQFLE1wU05fTif8qjfZ3j669a2GrfktAbfmn4BqND6gXJIF+CEPZx5F1Pwnf0buTop6sfgkb5g1cGeKXrhq4jh2SSvaI9ss1BdWSERGgW6NvD/UcQ+T++BChbF15InwFTihTjfz/bKx79gPh67DpCEV66w7MlG4Z7AF/6vRqSnmtfDnnxE3MnztiEllLPJJcxA/XjJUMLCuq3nO/XRt/Ugr0AAYNn55HSyVtl4DwhkNJgcBPZjAY2aw/3srSoJzfFFG/FjhYPmmTpi3OUMB8c64rRirBIvvinV5FAihHk7immf5m24qmJxmnQNr8l5vhdff0oXYf7EyDQoT26UIgec26FHdHSwL4RVgVBVm/XBh8tV5kDcz/l2tTP2Xk78DWEMZzIU5sQUuANICqDhTKK3i3ryYV1oaJEISv8+B6FuFBTY8ugg13+9FMZMJZ4wfhWGuYhqskICc/iUsnIDhjx3RA/UHfB/YCqACQdQCqYKL9uBgV6ba2hEfOjHfNbLAIDDlidZpFKEGLgjQZDDZ/p07fD0q9r27mG/9JZ8dRM8cU25liMkFhbDSfyhtxPTqZYjvAGVqeutRCrXT3fYNoOgJ5nC+cnCKSYax2v9uTlcITv9Qn7ImfH11g7 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: Matthew Wilcox writes: > On Mon, Mar 10, 2025 at 10:13:32AM +0100, Toke H=C3=B8iland-J=C3=B8rgense= n 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 'stru= ct >> > page' as metadata from the long term point of view. >>=20 >> 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 { > =09unsigned long flags; > =09unsigned long memdesc; > =09int _refcount;=09// 0 for bump > =09union { > =09=09unsigned long private; > =09=09atomic_t _mapcount; // maybe used by bump? not sure > =09}; > }; > > '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. Ah, excellent, thanks for the pointer! Out of curiosity, why "bump"? Is that a term of art somewhere? And in the meantime (until those patches land), do you see any reason why we can't squat on the middle bits of page->pp_magic (AKA page->lru) like I'm doing in v2[0] of this patch? -Toke [0] https://lore.kernel.org/r/20250309124719.21285-1-toke@redhat.com