From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f47.google.com (mail-dl1-f47.google.com [74.125.82.47]) (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 5D1613E0083 for ; Fri, 15 May 2026 16:04:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778861051; cv=none; b=iya39pjxkVgh0gp3YHdwpf66a50/WX23Wt6QV+LCNQSDeLqX/BcZF7xAVWncLgKMqhlvTj4Z/3FKr/yQBD8gjYf36LUkJsm/3vx2UQsDhwTzFchywQKqNH2YeejZqrD11z4ZcX6cyAB5hsYQgblDXXWIPlEKL8nh6mPCjQLuKmg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778861051; c=relaxed/simple; bh=XNkOvS6s1PYOUKWsJBvz5AjxhS3FOot7GCdK5Hh9glI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KH6VoRPNqLmiENLmDm3nxplwK7/jVelXDGjIO69RwzTtmT/61N6Ss16vPV71nfA5/YKU5T5pPCVd+/Zcc/uehMEOjhZeNFMWWIg3cAH2ZIHBGf+rn7I8t1jfk4zS2/+IoUsfvtoTvvp1G5PkMAM5mTcaVi5xlb9oAL0fA78YXNw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=IXkfBj0/; arc=none smtp.client-ip=74.125.82.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="IXkfBj0/" Received: by mail-dl1-f47.google.com with SMTP id a92af1059eb24-1329fc4bf77so1913209c88.1 for ; Fri, 15 May 2026 09:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1778861048; x=1779465848; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IR0rNGcBnxTQKxjl29BD/qgYqn9i6pUVwOw+iwSnTf0=; b=IXkfBj0/cG72R55XWqKF6YmnpCQ0smrGScB8FC7G18jnf6vvB4JIypmbpu63215sD5 98GcVcziQYFqeDueSZWYq3ML6/nFErfBJoGY08kizqt1MESOToDRH32sIstaUVg3Ts2p 98Rrbxoe5Obo26G7MUPcRRpypeZM9UpJNOK2APTO/5N+0OxLuwblmHxTzqQq5eFsQO8d h53srMNuRX+qI1lz/Uff4zLgZqeqcAoqOkV62vEnZJYk9f6wFHXgWZumXi7uArTpIq3f Zee+4mkIdEIXcZqiKtn51Iep4AcLBVZa0tp0fnPeO/+xO0DTnXKxtjP9OWeJyggESCWt Bxuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778861048; x=1779465848; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IR0rNGcBnxTQKxjl29BD/qgYqn9i6pUVwOw+iwSnTf0=; b=cn1dLiOHxEQAWpjIzwkHCJxsbFE1z7gH78dNqexlNFLOQVuiZjtB+nEfLg+ZJ2Yo6z 4FsmjlElG2WNfUuMkEHQFzu5IV9iXY04kBuwkOdnAtHo5w5m6lyD4BFJWEMbD0e2MDzG k5OqQkwole/e5VzY98C1J0otS/GsF3NRnbIHsShstUkureNKDzHmr0BIUqJUjbN4hQ7s Rhf5k1jcN0MRd/gUUFA0Vam4o6cS4u6dUrSe+LunxwmD4ndHmQzuse3IsnayuI8wZNdj EpEzkJ/nJwrfEcy5+buRrYqTKXOOTzXxcqE1Zqokb3Oyp2eouO6c9iyHEXrCGv2K8iFa mMkg== X-Forwarded-Encrypted: i=1; AFNElJ+/RzHTAo+ukhclvGy/fcztxB/nM8XTqn5VrC4TpAA+sCGEp7B9aZNbqhBQUnWxI41GvXZYFiAccMjM1uc=@vger.kernel.org X-Gm-Message-State: AOJu0YwE8fy/yr6bPB8riPyez8pDa6MHZDzo3PK/EtEnkaYGtBLy1MXc 6l+kvLy5C5bNvudLb/npS97oK2WEsDGaMoJJMvaLGzgaKXp1WjXUuzd62nux0DV3NXA= X-Gm-Gg: Acq92OG+Y+h/sSxS0a5IklzH7kecyr9NCF6RFVVnVND6bEkBVg9+7tlk742czc4IQ7F W0w/zKZg71mXtcxgQHmmxNy1i/y71eYwYEeM+MrZwx9PRikJBEXkImScvWJF3TQ9LzkFPvcU1Mf Uwsxi6Z5V9gKZufhGg/6j9uG2YueJr+sXUOKeZoKg6KsquTJ/l5hp9MVX0Esjsf2uH5lrOHNBNX g9FQPDV9qVSWYLKC3CDfyhhKxrV7Szd5VrnCgfq9DCXA2TNWED88gmqstMwtTpLwPkPw5cYmpNq CZOQIqnBr+E8WD+EPO6kWOaFj5+1xlYEcCl5KK5exAgx0lm9quGoLgoXhPmyz4XUK28B/MNS2OF QkJpnYyHTQnXKfuhftecngolfiztGsgZvELg4ggwgeB6MZQ5Pi41ACly66YqkL4a9hqoD0GXVdc xBKDCVCEvlOEUlghjkuqq6/0ltf8UdwJO61UWW5FNpi+RKioRBVk3rmoBHk8cbD4LHx+obJM4AL xxLYvYIbSvB X-Received: by 2002:a05:7022:41a7:b0:134:def6:e70b with SMTP id a92af1059eb24-1350451e322mr2242686c88.6.1778861047934; Fri, 15 May 2026 09:04:07 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-100-36-248-188.washdc.fios.verizon.net. [100.36.248.188]) by smtp.gmail.com with ESMTPSA id af79cd13be357-910ba36e638sm580427285a.9.2026.05.15.09.04.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 09:04:07 -0700 (PDT) Date: Fri, 15 May 2026 12:04:05 -0400 From: Gregory Price To: Brendan Jackman Cc: "Vlastimil Babka (SUSE)" , Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, rppt@kernel.org, Sumit Garg , derkling@google.com, reijiw@google.com, Will Deacon , rientjes@google.com, "Kalyazin, Nikita" , patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Yosry Ahmed Subject: Re: [PATCH v2 00/22] mm: Add __GFP_UNMAPPED Message-ID: References: <20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, May 15, 2026 at 09:31:15AM +0000, Brendan Jackman wrote: > On Wed May 13, 2026 at 5:59 PM UTC, Gregory Price wrote: > > > > struct page * > > alloc_pages_special(enum buddy_context ctxt, gfp_t gfp_mask, ...) > > { > > switch (ctxt) { > > ... internal-only details about how that case is handled ... > > } > > } > > > > and just go ahead and allow the buddy to grow internally without adding > > new gfp flags or an infinite number of interfaces. > > Yeah, this is what I'm thinking too. I don't think growing the interface > is such a big deal if we can put it in mm/internal.h. For __GFP_UNMAPPED > and ASI's equivalent, we would eventually want to expose the functionality > outside of mm/, but that doesn't mean we have to directly expose the > page allocator interface itself. Do you think it's a similar story for > __GFP_PRIVATE? > The important thing is that the API growth, if there is one, needs to be extensible and not specific to a particular user case. alloc_pages_unmapped() is just replacing a GFP flag with a function call. Now we've encourage alloc_pages_foobarbazbazinga() to be implemented. So we should give some careful thought to whether growing the allocator interface is a good idea at all - and if so very intentionally. I made a similar comment on MST's virtio series [0] about trying not to increase the buddy surface - because it makes it harder to test and easier for people to do the wrong thing. So if we are going to increase the surface, maybe the intent should be to have an eventual migration, rather than a permanent surface increase. [0] https://lore.kernel.org/linux-mm/aeozRZ9AvW2jTQkX@gourry-fedora-PF4VCD3F/ > Anyway my initial thought was a variant of alloc_pages that lets you > directly specify alloc flags alongside/instead of GFP flags. This is > actually a bit fiddly though since the GFP flags -> alloc flags thing > isn't a clean division. Maybe it should be? > This is actually what i meant about some GFP flags may more accurately be described as alloc flags. They say something about where to allocate from rather than something about the page itself (ZONE_DMA vs ZONE_CMA vs ZONE_MOVABLE, etc). > > Of course that means users have to know the context in which they're > > being allocated. Right now you can kind of "transiently cheat" by > > passing a GFP flag through a bunch of interfaces and that makes certain > > allocations reachable - but maybe we should not be encouraging that kind > > of design for these kinds of allocator extensions? > > Hm, for __GFP_UNMAPPED (and __GFP_SENSITIVE in the future), it is > nothing to do with the allocation context. It's really expressing > something about the page, i.e: > > - __GFP_SENSITIVE means "We might put user data in this page" > That sounds more like an allocation context which implies a set of GFP flags, rather a specific directive to give the allocator. > - __GFP_UNMAPPED means "We might put user data in this page, and I know > the kernel doesn't need to access it in the direct map" > I don't think this necessarily implies user data, it just implies wanting an unmapped page. The caller's intent isn't necessarily encoded by this flag (although we can derive it from existing use cases, who knows what crazy stuff people will come up with). > So, for those cases, I think a GFP flag is actually conceptually > correct, the only reason I can see to avoid it is because of bitmap > space. > I don't know that we can call any particular idea "conceptionally correct" when GFP flags themselves are a mishmash of ideas already :] which is actually the core of the issue isn't it? n_n;;; ~Gregory