From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) (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 9259141C31B for ; Wed, 13 May 2026 16:17:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778689080; cv=none; b=Oi0+xQ6pCKoQNLbOtSh3W3egEcP80V9sxstiymGtOIQK7k54GqdHjLTdAcXVnaGxl7voVsgchWDoGJ9ZV/RRStk578+Ve97GCsYdBLoR37XmFmJ1F1bMJiiHYbU5xFAQAyiiqdZmy27C6sGeNarvi9v6emNdIH/hG9ndeiGaqIs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778689080; c=relaxed/simple; bh=2RK3FKFn4K43Q4M6NDbl1g1A3QM/bkVVJQaP/9OORjI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ubYArIZ/OhjumPhTLDnyViPkSQY32gjJ/scIEeynCTaHR2EM6ebh01VGvMBUadNDptq8m0YGRmjOgGSeYJpqCruGVMt31jYNPyFrYJPSoqhy6Pr+/sWT3iBW1ZccSV2YJ0Toh0SzwceRCKzJNe1CKlnovNhDX3H68RHINiidzh0= 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=kEW637Sp; arc=none smtp.client-ip=209.85.222.52 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="kEW637Sp" Received: by mail-ua1-f52.google.com with SMTP id a1e0cc1a2514c-95ce7b777ccso3891330241.1 for ; Wed, 13 May 2026 09:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1778689077; x=1779293877; 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=rt9FBP1WGsw6Z9zRkqY/PuoLWJVlBgBrADxve8fjIWw=; b=kEW637Sp0LcfPdpimHcnK8t0AUejS1NVLCHEtgwYPPDVO0Gv9xEFLl7JZyvkklm03Y 7MsFj1ITFf8yj13Wx8L85deP7kP/5ONbAsE68QTNauTH1DMNi14FFitErbAY8wy9pIFC fG+UPTB/QQ/+Uwq8Wf0Si77FDgAxW3QeGIEkASqzSqbcH74Onw/HGPcXKvneU322xzlQ Uzpim5YVY1RC63l2+nr/jxYENmePIYSuo/nXmP/M3IYO9mj6sBtC66hr0rgbsnypifL5 B2GQyiVpvba6pYE/m37TVb0YPexNoYlVzC7uK11kUi3hg/u/DpbJxYcr1IM+TTcQc2t2 /7Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778689077; x=1779293877; 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=rt9FBP1WGsw6Z9zRkqY/PuoLWJVlBgBrADxve8fjIWw=; b=Y493mzSeD3FvTJwttRAxkzdw24h6k4WqKf3eMtuuBwxisuro8LtP4S+JlCrKdAZWin E0vvhy1M0plKhP2UNmZEEEbbsRPgMfJF2fOQALlbtaCtFBM2d/IJuAYME68DOcj4niFS 8Z44pR2SEGHJsTPVRKoIs9OEdw4VQi1ueNOr/KcrssO+8gMeWAuOpN73hCE9LFDOnrgh HXhoXn0tPaGt6nCYL1QXJOc33pIxx5Uh2DD5P09G0wyK2i+EJAM5kKQlaPsNGgwfWqtS ClAtYywhznxEpBCYkjkCWlejh0r5gWKMtJbi1Q/gdxfX6pAYBkljLpBe+zV+92KLQhSD g+aA== X-Forwarded-Encrypted: i=1; AFNElJ/LXSGakdRif/jI1yfEVaYMs4kaNIY1B3qjEG7aKYOwL9MuMuN4A/5qxBSKlw74LJzDbNGwOtgRGrmLPkM=@vger.kernel.org X-Gm-Message-State: AOJu0YzcrTuKnofzfOTJXlGWkGYXNX0rZZnUOSZ5FSKKzWYpITAcpLb8 0G7V1cJ75EWKqvMOWbDaEQXPQ1jcR+OdiilpjLI/RtZdLm5MDNgbzkjaeLEqtHwRFobqHirxLi6 dKBUC X-Gm-Gg: Acq92OG9FA//vY5Q1O1wWAGs2M+ngE0sR/+u4w+zn6erZ0PQPIXqyzCKV+cfKygAhGy /ZuHB54KjD2Y14ookgT8TTQmtVa9Npj6CMwLNdUZwG4g6payBHIc7f2JnHqYlS5Pv0u51gVr9Yd Wy7p3VvCbpBDW2EmJO0y0wEfZXp+wgWJ8uRTlFC6Z5bn/j/LAwMpoNr5irsIdWu11gs1bYTEOqm VZcD46d0Mj9nedqLTzuqjs/iJohXfMg4D7YPT9rNAboE2qFOae1CouoIzygImWu+F5zl5+P5vhG kJ5LlYvbkDG+2XvdWj/05xFt/Nv0frBKHq+wmQbO5DDet6mfssXGAYpG4r6JXO5IP2OOL4a1RWi v6jOvU7RyZSLDBVXIqrCNiHP10dm+9nyAO1dZ1yw+Fxov3hV6tdCrqNSKZAtkrpISYKKO+aWKD2 0u8nJDzr3Dz4nReF8QjJ0YQ5skZNKOY7erPk2mrrvuhceSJfrIpDP2DsrKRi5F93ORoOYmZ7W5b WXYnreks0G5mkVSzHqGNvg= X-Received: by 2002:a05:6102:441f:b0:628:95d9:9607 with SMTP id ada2fe7eead31-638b4c4ffffmr152334137.2.1778689077262; Wed, 13 May 2026 09:17:57 -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 6a1803df08f44-8bf3aed2920sm158507606d6.7.2026.05.13.09.17.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 09:17:56 -0700 (PDT) Date: Wed, 13 May 2026 12:17:53 -0400 From: Gregory Price To: Brendan Jackman Cc: Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Vlastimil Babka , 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: <20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com> On Fri, Mar 20, 2026 at 06:23:24PM +0000, Brendan Jackman wrote: > > Because of these ambitious usecases, it's core to this proposal that the > feature > overloading the concept of a migratetype, this extension is done by > adding a new concept on top of migratetype: the _freetype_. A freetype > is basically just a migratetype plus some flags, and it replaces > migratetypes wherever the latter is currently used as to index free > pages. > I'm a bit confused why the need for additional level of indirection instead of just adding a new migratetype. You still end up increasing the migratetype matrix, just with a new dimension. (apologies if this was covered in prior work or discussions, just now plugging myself into the series). Why not simply have an unmapped migratetype, for example, and on steal you convert it to movable or whatever the preference is? > .:::: Hacky bits: simplistic secretmem integration > > The secretmem integration leaves the mmain optimisations on the table; > the security-required flushes of the mermap areas are implemented via > distinct tlb_flush_mm() calls. It should be possible to amortize the > mermap TLB flushes completely into the normal VMA flushing. However, as > far as I know there is no performance-sensitive usecase for secretmem. > So, I've just implemented the minimal adoption. This will at least avoid > fragmentation of the direct map, even if it doesn't reduce TLB flushing. > If anyone knows of a workload that might benefit from dropping that > flushing, let me know! Crossing a couple streams here, I wonder if there's some mechanisms introduced by MST's latest multi-zeroing-avoidance [1] code that might help deal with the problem here. MST wired up an optional user_addr into the buddy that allows us to sink the zeroing step for folio_zero_user (or folio_user_zero or whatever) into the post_alloc_hook - which includes some cache flushing. That conveniently gives you what you need for a TLB flush AND an indicator that the allocation is intended for userland. Unless I'm fundamentally misunderstanding something, the pattern at least seems similar. In that sense, does this just become a post_alloc_hook that unmaps the memory after zeroing and allocation? I get the intent is to have the majority of memory unmapped by default, and then steal those blocks and map them as the kernel requires more memory, but I wonder if it's cleaner to do it the other way and simply have the buddy unmap on alloc after zeroing, and remap on free. Seems like the free path would be trivial, check if the page is in the direct map and if not, remap it and move on. Entirely hidden from existing users. So, maybe a stupid question: Was the opposite mechanism considered (unmap on alloc sunk into the buddy), and if so was it rejected for some other reason? [1] https://lore.kernel.org/linux-mm/cover.1778616612.git.mst@redhat.com/ ~Gregory