From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A39148248B for ; Mon, 16 Mar 2026 16:01:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773676893; cv=none; b=NY4c9Y/wZ5abwZdbVA1buzCclAFxMW+l6V0qh2cVjfTAeAz9yq8M33q5U0inBOdfl+j6+OmWDk90x0/TRPApGjoBgKjxdZ5+blZMmQkmN/Ge6nIb3nWqAajhKh4KDjhbvu8dkvL8fE32odDBI15ES00RkVgKpgBxztohTbdaIeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773676893; c=relaxed/simple; bh=/l/g+Z3TUgrpVvYsl5Jqhaomsxjf+N1trtozHf/goss=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=jBQ18SmnOS4wz98v1iZqlnpV9qTA1PGf3DZEBouuB80EcWhKG4rq46yhaQfXftPIUp5zOMG5v2oUF9RXRwRL7PWl+uSQ6unDigztuA8gpFrRrDmVfhMuFTJ1bOOmyviCPmLgRPjwPF0fy66u3Yz+V2KM8S42jVRoCczfIoz1FZs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GKmiXMHN; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GKmiXMHN" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-4837b6f6b93so36485505e9.3 for ; Mon, 16 Mar 2026 09:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773676890; x=1774281690; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=cy139sVJqEhb40Dyk/x+cPr9bRVnmTHD3vwfuMx6Iog=; b=GKmiXMHNxZwQhYesILhvGCjBcNiUAaGQo1OARP2ZakmpFos591qJ8i+l1OlVYkNqo7 vrwwLpXZyCwN8fMzQxLjVa6sXStdNofHoNg/vT3/FY82qmWaAoMmWynWhN+0X6blU1Qh Udl/+hGDTKC9U91TejrYywvY/H3RTz/Vb+qkyJpBtx4Xzp3i2Gs6Hxz6AA5yDs1Ajw4Y 01mfBaQpS0kt9nZygaXYrK360uFivRUOWEJr5SlWQw8hYo/V0qI1Gd9t0jq3LZbgJY08 C7NEOXAAf36RgPUumSZnu0uic2bis21lHOk35CqJtZ0pw+0BXauFzLwLQuuhncZd9Ig9 EybA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773676890; x=1774281690; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cy139sVJqEhb40Dyk/x+cPr9bRVnmTHD3vwfuMx6Iog=; b=hixqMN2ZFAR4DKYQzmOMjN4PhO910fbpHKGQrGlna3yxX/3wWYZyshLauvubVrZE/k E3SxMDoJa9mlKslLV0Abk+54jiDHfKCIFZdHaaWuYL719+ggdZJ216BLBJBw4PtLbv9b szpitIjfBAV0mJqtLsTgmZjkhedJVX4QSDhU6Iq0cD9D/hxDXOWxgXUO4PpZWBuDAhuX g1NOC2OMkEb2+IQV9IkvAEuyAFDltiu7JxubdGhaNCdz/wU/HaR79EaUtBZtFqsI61Ms ggy3FTOe4I5lz22rl357jp1tIynG7OTvZoNzcAfTzhHT2FaMCUNTu5Kttjs1dqraUN9X jW4w== X-Forwarded-Encrypted: i=1; AJvYcCVeAWLQICrYS0c1srCu6DutqSCX1YzuKb+I8br19aVVxiJmO5uqyP6yVoOgYPUaW87LlyYJR7/WfOmnmaM=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/ZjUsMZKK7BqmyE6Edcd0oEMdbmy/pbJBvWDA38jDxEJa+4ZC rrSWtI4uoDQdlIELp4VcoxjuiXiK9U3hgSufBiwL7S35fiLhxJwBV9v4v3Nu8B69hvf/W+/Qv/a pYskY8nJTcS6mNw== X-Received: from wmpl26.prod.google.com ([2002:a05:600c:89a:b0:47e:ddf0:fd00]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:4e16:b0:483:6d4a:7e6d with SMTP id 5b1f17b1804b1-4855670cd92mr222236695e9.30.1773676889811; Mon, 16 Mar 2026 09:01:29 -0700 (PDT) Date: Mon, 16 Mar 2026 16:01:28 +0000 In-Reply-To: <5d22bf8810fc18c326e1b12c90994a72f74916a7.camel@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260225-page_alloc-unmapped-v1-0-e8808a03cd66@google.com> <5d22bf8810fc18c326e1b12c90994a72f74916a7.camel@intel.com> X-Mailer: aerc 0.21.0 Message-ID: Subject: Re: [PATCH RFC 00/19] mm: Add __GFP_UNMAPPED From: Brendan Jackman To: "Edgecombe, Rick P" , "jackmanb@google.com" , "dave.hansen@linux.intel.com" , "bp@alien8.de" , "david@kernel.org" , "peterz@infradead.org" , "lorenzo.stoakes@oracle.com" , "hannes@cmpxchg.org" , "weixugc@google.com" , "vbabka@kernel.org" , "akpm@linux-foundation.org" , "ziy@nvidia.com" Cc: "kalyazin@amazon.co.uk" , "rppt@kernel.org" , "luto@kernel.org" , "yosry.ahmed@linux.dev" , "linux-kernel@vger.kernel.org" , "reijiw@google.com" , "linux-mm@kvack.org" , "itazur@amazon.co.uk" , "patrick.roy@linux.dev" , "sumit.garg@oss.qualcomm.com" , "tglx@kernel.org" , "will@kernel.org" , "rientjes@google.com" , "derkling@google.com" , "david.kaplan@amd.com" , "x86@kernel.org" Content-Type: text/plain; charset="UTF-8" Hi Rick, sorry I was just scanning over this thread again while prepping the next version and noticed I never replied to this. On Fri Mar 6, 2026 at 5:38 PM UTC, Rick P Edgecombe wrote: > On Wed, 2026-02-25 at 16:34 +0000, Brendan Jackman wrote: >> __GFP_UNMAPPED > > Haven't looked at this in detail, but there was some previous work that even > used the same flag name. In the end, the discussion leaned towards a dedicated > API instead of a flag. Not saying the flag approach is dead, but might useful to > explain how it fits in with that discussion. > > https://lore.kernel.org/lkml/20230308094106.227365-1-rppt@kernel.org/ I am not at all wed to using a GFP flag for this, but a key difference between this and Mike's original __GFP_UNMAPPED is that this is integrated directly into the page allocator itself, and that's a load bearing element. Technically speaking, in this series __GFP_UNMAPPED is only supported for unmovable allocations, but that's just to avoid bloating the data structures (there isn't a user for that type of allocation yet, so there's no point in creating freelists for it). But, in principle, the goal here is to support all the fancy stuff that the mm does for this memory. That's important because for the real usecases I have in mind here, the vast majority of memory in the system should eventually be relying on the page allocator to unmap it (either completely as in __GFP_UNMAPPED, or just from the special ASI pagetables as in __GFP_SENSITIVE, which will be added later). So, yeah we can always have a special API but that would be a bit of a roundabout way to just save a bit in a an enum, it wouldn't actually represent any simplification of the page allocator's API. Anyway thanks for pointing this out, I will neded to explain this in the next version's cover letter, but in the meantime there's a quick braindump of my thinking.