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 CAC3EC28B2F for ; Tue, 11 Mar 2025 15:32:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 670A5280002; Tue, 11 Mar 2025 11:32:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F662280001; Tue, 11 Mar 2025 11:32:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 497BA280002; Tue, 11 Mar 2025 11:32:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C5F81280001 for ; Tue, 11 Mar 2025 11:32:25 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D523BB18F4 for ; Tue, 11 Mar 2025 15:32:26 +0000 (UTC) X-FDA: 83209661892.22.2D82D9F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 6FF5A140022 for ; Tue, 11 Mar 2025 15:32:23 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Q+gwuqDD; spf=pass (imf09.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@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=1741707143; 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=QSVUVdzrrPa7xD4r1VlLxI2M6gTAr19eCrMDPnwR5Nk=; b=4J7zzYHAAfwzHnBkBeZNaa2iTKT83HDmC5+SF1CHPlED2crBBoG16OLgOFi73J9K0Puz2e l4vAk5VB1yqGEmot7DSdoraBUbVZyqEJrOzENLM0Pr1m3K49nnKhMxCdeO9TKRlR45xW1V NS3tbL+k4IlL6wxHa4gOWHyWNWO1VhM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741707143; a=rsa-sha256; cv=none; b=uNW40FtwFa0IuE2bYpu/4XM7laWwSrUwsme8jv3PVlkfAz4C7MSQhJD/Bp825or5vVs2To cDK9Ezs4D0+IRcl8PXz4sv4CRKSC51No2Bi+ckBUBsStADlyEOytiQORDJEJbpOxlMRUqq droPs8qQRyD6mD2Y7VqRVXJ3jE/pkqE= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Q+gwuqDD; spf=pass (imf09.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741707142; 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=QSVUVdzrrPa7xD4r1VlLxI2M6gTAr19eCrMDPnwR5Nk=; b=Q+gwuqDDaFVdXgfL0mVPZHNj60ZhRXIH5CWFGK26LH2czUqmjUrRp0hgdTKirMFXH7UDa/ SWSsxwzg4+8qouk9zXtaJfR79m+dpia3WA283P1mpXeoeK3nD0/4P0FJtZ9WlcrvkC679h m/PDpg2bSBS2gegyfT0EjrLb7xzZuUI= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-663-wa9E5qbvMKK6epqasIoG1A-1; Tue, 11 Mar 2025 11:32:21 -0400 X-MC-Unique: wa9E5qbvMKK6epqasIoG1A-1 X-Mimecast-MFC-AGG-ID: wa9E5qbvMKK6epqasIoG1A_1741707140 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-30bf320ea2aso23446111fa.2 for ; Tue, 11 Mar 2025 08:32:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741707139; x=1742311939; 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=U/aeAG4OEnJZfzD22pIVzeanaB0d9wDGvhn3exEQ+LY=; b=mYUXHltxmDEqck4xClXmA9IqDkFr5qlIwAyK9rFPWQsYRTpCEzxZIPtuQEEZ1jv26O ixuR2LQJ7Y12g9LrYfXF4GBwMRkQftit9fu/F/PFS9Wz/owuZiNSuOPh9mimmWR7FpyW nSCtQDOCpWbKKzWstE9Oq2NW7O8ElpKsjaBUiN4nFk+/y6BSh53ZbKsAU0fFGW9KNIgv nidqFOWbFiajasQHXuG4nur7h6uNRopV13I6mooPJGZG9amV6vVE8UYqGn+KOm8Z8HAx RdLGqjp1draKxgLZM4X9HgXWiUYXRyGbZ+LisJsTJcKKfz7EriOq4dpsEozYS2IIR71V LaLQ== X-Forwarded-Encrypted: i=1; AJvYcCV6qXGFkLZbbpjZ9yGJQctNJfXIcLRVOlCn2b0i+aTfCORv/MROqvExzTvfDWXOuBtAqesjVJ2YQA==@kvack.org X-Gm-Message-State: AOJu0YwuuutX0I/aAWnuWHFimkvqZ5kbjb+Y8gyhm5leUVPtTZlxRTcZ OaT5mlEjcMSsAzMuinL0GsX/jjKOnYshF6zOzBZwe7atfuQQ7J/x2qgDoITEntdA0qASomIGR/8 tK7K84Ho5d3vn31QIQwGkI1GSfmvjR7WavVPi5C/eb6wkSZn+ X-Gm-Gg: ASbGncvmb5P+kbBnmMGLP9mcTnSD+q/5GD877rD5O8SsgSJGQY30opCaQH8EmdQyvst sOqExjznzaY8/HwOcdPBvT9EH9eTI1tkn0RYOEL6XZhO6GACiXi2CBNwf2ZD/Dt88FE2glzAUEj PjZPTm9QDHt+0pS/dVTiJsg3rtHrBORl3AtT/cxEcTuUwcbWpe8UBvXSACuQIoM5NJLIkTnGHgX oam1k2X85eu4qpEuexurtTu8szHjvm5xL/aD97HpjKozQxtfbF3iP3I7raVbVYJXvk03tJ5kTp2 88ifYe3eax0q3qznIGBR6h6DEvRSgwSybTzc16gu X-Received: by 2002:a05:6512:33cb:b0:545:1082:918d with SMTP id 2adb3069b0e04-54990ea9415mr5414965e87.41.1741707139351; Tue, 11 Mar 2025 08:32:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFtToLR48XY/sMDb/n0VeIObaGddW28sS6byawDqUxKkYJbllV+n3/4P2p6e6L3IoZTX2EIag== X-Received: by 2002:a05:6512:33cb:b0:545:1082:918d with SMTP id 2adb3069b0e04-54990ea9415mr5414951e87.41.1741707138956; Tue, 11 Mar 2025 08:32:18 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-549b126462csm20694e87.244.2025.03.11.08.32.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Mar 2025 08:32:18 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 1CB5C18FA5DA; Tue, 11 Mar 2025 16:32:17 +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> <87v7sgkda8.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 11 Mar 2025 16:32:17 +0100 Message-ID: <87ldtbinwe.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Kg-oImWJMMufyoCSA4eVpKfFeCwyXSJfEi30ZzvcgTY_1741707140 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspam-User: X-Rspamd-Queue-Id: 6FF5A140022 X-Stat-Signature: bw8d959cq55frotniqybso6j9t3uyy5i X-HE-Tag: 1741707143-692833 X-HE-Meta: U2FsdGVkX18D2jaELtT4S5rdBdXRYvKXGKZQslk2CJ7fdfzENq1ZK2AJy8hPzzfLLdte6o0q1HGsuc4gUr6O6X5yilv7yIsft6JYEgsUTAnO9uxWEno6T7Q56lytLQ7MxI2dCFQdD/s4sX854tV/il8WVxy+ucWPsEI4KMF3Rsil3I9j/xUe6yMVSGLiWgNjET2KInYPdDPOpAuKJftAVmtnHipFcKJoBNiSJg6hAy7trMg7uZTb8v3RHJkt3gXhD+VnZeDn47gGOTRhtMZ5XvH/klZm5yjFxPzxRTRCtLNOShXFXRVrigY7FBsLugn7p57qeb0qwy0OnF4GPn7kN0zL0nku+NiMPU8MDcD544hg0LgwrGw1Q7Q/l18IGAB+ybZEJGhM8B64uSNvlqlVMHm6PFhdMzKMLsbx/zU2E35rU3FU5KYv6A6jY+cADZlGvyAn/4xVccrSJR2CpRluT75nQxnRlRsGPDW+d/IggH9UD8D/jGvkXQLWCSPCSV1CzgEvaZLKq/PrudNUF9TbHJrBRtJ4YOAlQT3NpEd31d0TYxW2pLb8NZILrRODoKUWIr/EDzfa1w3tT9+ngHzKMi/4akubJYt8iL8YZhJ1O7lWhxwsAEROJDyspfRH+BfYWC7paQjMuA98f9jQ9OBR++K/FhZzu05KGCX4nSgX0gupA8HFKlEeuXSEjNHfv3vwOWgR6DcEgwQ0EIkrQGLPAgYnmpBui6R9hvjPgSBT9Kjio0uFGmTgOhxL13/Pr20Ia812e3Pz/9J9eGvEnc0dG6iVm6ayLRZ/7QQ66wvaAzBanGfcx9u8Z26zob88a5txFGRaIdiWrNvS/5UnMpqtid9jEOz8lChUdSHN5R2cPwBpkXi0zqUygThFl1MMauo28HS0iE7i3qcV7soD1Cjspm0o4SybEZPvKVx3+38kH+7NbELBqlxSi+skFKF/1RCszE+AearILrRbegrbfiU M/nqSQM2 /GBT5yHVgVFMDls5WRbtG2NRG8HZBi+R19uK/Mytx/1IzIqUaQ8oAZSc67er4IVVaSmEIf1N+dIDjnzOwerLApMScE68Ffi7OqCdb97uXEbhP0CShmOl52xfC0/vwUMCss+hFRrdyXRUnefg+d4DpYE9r3a0EJoa7hoXuB8LHxQDWPpoDjjgkWv3XCIovSWnW9La+GzJfAVcr7ybM1HHGhoZ2Uq/9N7omEDWvn/BNQPxF+kpf4ATSkuT/dXvPbSgK8hTKj4OoPlVvw5QQTieNblI8WYjI1gvigwD1g98ygg/o8JO+JZD4hU3X7qwQYltOc8w+/RoanBAw8i73+pJWqU53CMFfm8yivZeGPNKoATgysnujI60H3YJLjhjH5hTEBYtOinIukW74pQVDJew5kgNznOp0wdke2qn/WIFfIbEJci977msXfrFfKhVmfP6jXDEsfMMgO1eeWpCH5CxCejuLZwp/ajL/okIHp3ArIoKYZ2LsUlxcLeQVmK02TgOtOCk1EN5Apz6GXPXDNIYLqj787CJ7CKA/irFQzL/IeZDYYSE= 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 06:26:23PM +0100, Toke H=C3=B8iland-J=C3=B8rgense= n wrote: >> Matthew Wilcox writes: >> > 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 a= nd >> > "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 o= f >> > 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. >>=20 >> Ah, excellent, thanks for the pointer! >>=20 >> Out of curiosity, why "bump"? Is that a term of art somewhere? > > https://en.wikipedia.org/wiki/Region-based_memory_management > > (and the term "bump allocator" has a number of hits in your favourite > search engine) Right, fair point, I was being lazy by just asking. Thanks for taking the time to provide a link :) >> 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? > > I haven't had time to dig into this series. I'm trying to get a bunch > of things finished before LSFMM. Alright, well if/when you get a chance (before of after LSFMM), I'd appreciate if you could take a look! -Toke