From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-194.mta0.migadu.com [91.218.175.194]) (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 E597D3E49D1 for ; Tue, 18 Aug 2026 11:04:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787051046; cv=none; b=XBRHaUdAP65ybbv7gyDcaz3c0tFh68Bg8aARc/NoOssZJ3SRJFiYI5vVbg0mf3tbWjQGeWTL0/EQ/MJCm5xPCDodOc0DEsfeDA+uz2GauuhA38iurJmdLvo/9WsuSfNdUJ5I0u0rDglbKuWcXO6lTOFW2PwE8ycWv0yYqQ0f50w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787051046; c=relaxed/simple; bh=MWi4mSbgDzBcEms9pNWhuTCHSm4bPkMWdlMUVkjUkxk=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=abIXXXnwEZ6NL6RAliY/JLs3FUcD6hAyW09YWXeLxCtOpiHkTlnRzstsBbmTi4XdY3+LsSjnqP2P6diTh22DCLN49BA52EAiCB8gNwcyZVKD3FPcPBcu7YSes63Ao9+9YsQd7v9DkuSgwRNmwbAVfiRc8bbM52NZHYalSo1nhHQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=V5L/hW8R; arc=none smtp.client-ip=91.218.175.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="V5L/hW8R" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=MWi4mSbgDzBcEms9pNWhuTCHSm4bPkMWdlMUVkjUkxk=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787051042; v=1; x=1787655842; b=V5L/hW8RUYoITH5qbQVyLVBtzMWyvQD2ab3lU7BY15C4bDbhPmVFW1x6Shxguyq09mcB51Fv I1Lfj8aQbN05sa1Hd82iXtkgXhwCBKQlB1mB3q7l41XNgG8t5R9VTb2YJNNhWcrBeckA894AjcK HbTZGrzZL602ARvbjgyQNxZI= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (2a02:168:f6cc:0:a69a:f3a4:8fdd:3332) by smtp.migadu.com with ESMTPS id 7a9325f046949f8f; Tue, 18 Aug 2026 11:04:02 +0000 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 18 Aug 2026 13:03:57 +0200 Message-Id: To: "Yosry Ahmed" , "Brendan Jackman" Cc: "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Vlastimil Babka" , "Mike Rapoport" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" , , , , "Sumit Garg" , "Will Deacon" , , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Patrick Bellasi" , "Reiji Watanabe" , "Sean Christopherson" Subject: Re: [PATCH v3 21/26] mm/page_alloc: implement FREETYPE_UNMAPPED allocations From: "Brendan Jackman" X-Mailer: aerc 0.21.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-21-6f5729aa9832@google.com> In-Reply-To: On Tue Aug 18, 2026 at 2:55 AM CEST, Yosry Ahmed wrote: ... >> [0]: https://lore.kernel.org/all/20260805-shivank-gmem-migrate-v3-9-00d8= bdec4e1d@amd.com/ >>=20 >> > I wonder if we still need a fallback case where a pageblock contains a >> > mix of mapped and unmapped pages. We need to carefully handle such >> > pageblocks: >> > - For unmapped allocations, we need to unmap the relevant PTEs and >> > potentially do a TLB shootdown (if they were previously mapped). May= be >> > we should always flush the TLB for simplicity for now. >> > - For mapped allocations, we need to map the relevant PTEs. No TLB >> > shootdown should be needed. >> > >> > Assuming unmapped allocations are always zeroed by the users on alloc >> > and free, we don't need to worry about zeroing pages either way. >> > >> > We may want to track the number of unmapped pages in such page blocks = to >> > now when it's fully mapped or fully unmapped and change its type, but >> > maybe this can be a followup if needed. >>=20 >> ... However, yes this might be unavoidable despite what I said above. >> This was also DavidH's feeling when I chatted to him a few months back. >> The hard parts of it are a) the tracking as you hinted at and b) in the >> general case that means allocating pagetables.=20 > > I am considering a simple-ish scheme to avoid per-page tracking and > potential TLB shootdowns in the freeing path (which prompted async > freeing internally). > > What if we just always map pages in such tainted/mixed pageblocks when > they are freed? If they are already mapped, nothing to do. If unmapped, > we map them and zero them. No TLB shootdown required. > > We also shouldn't ever need to allocate. If the pages were previously > unmapped, we should have already allocated any necessary page tables. > Right? Why would we already have allocated them? In case it wasn't clear, I'm talking about breaking down huge mappings here. > Zeroing on free may still be bad, but not prohibitive, and hopefully > this is only a fallback. We'll need to figure out where this fallback > fits (e.g. before or after reclaim/compaction). Yeah zeroing seems tolerable. >> So yeah I think it's probably doable but I _really_ want to avoid doing >> it in this series if we possibly can. > > Yeah I am trying to figure out whether the issue is theoretical enough > that we can do it in a follow up. I think it's definitely theoretical enough if secretmem is the only user. I hope given that guest_memfd usage is gated by a userspace opt-in that it's also automatically OK for that too...