From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (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 D9B844A1384 for ; Wed, 13 May 2026 17:28:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778693311; cv=none; b=JWw05KcFOIgm5vPH7vyYmB5HCpf8bUel0zBXNdLamP/6nj1a5qfymoO8+fTMCS5Irn3E+URAgQ6RIbu5brZn+vPgz7aVylVBOOItpySlJmUK3JmJJ/TEZ88vo8ij80VntAuyDqqlxDE2XeSm/U25TiGUVu5NRos3oYNS6V4JTqc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778693311; c=relaxed/simple; bh=KlTzEBYyEiXChS8THUN9/ngqWKSs9Xf0pkY/BwkWgSs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mIPafBVPnmOrceBLE6QJkltIaVUIcd0DEMJU+gQsYFO+rg4GJioyBObK0O1CUQzVk8WCmp0M67cez0l5+nAWvDH1bXf+RrFmbbYm8/4HGwvHHNJoz6fjb1el3McVWmaOR2v8Ty3OhXBSnjEfm/QdyyQ9lN2SCCyv00g7yoXF4D4= 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=UST9o2/1; arc=none smtp.client-ip=209.85.219.44 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="UST9o2/1" Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-8c7154725easo17469256d6.0 for ; Wed, 13 May 2026 10:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1778693309; x=1779298109; 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=k/yihlsgioa3tb/oK9ngpjlNZtNgbvgaG/p//opnvnk=; b=UST9o2/1WBzgKg0jcAr3WE6q8wUL31M/XTYZFkHzqGColmaKMZXtI/Nmh0ullp3xZU HLsDnl4N9wpScST+RK7XK3GScwkX6h0PanQg2i2blwkkGEaU45oAtzcmtxX+2xEvMaXN KxJOLqmDHV3NR1JkRHxhG5k6UqQeN+V4MZb9T1j05n+WOAqgfUrT6/LOdRJzHah1aYe1 gRZ8/mjvVSNhcXjqvGU07Rs+7rZ2Ju4+PKq61wA47xCahEZAfFRV4zC8P9CwwoYqlDGm eYkEzEWljXWBI9rEziGc+kK6E8hpC9cDJtp+jyxHi1IeX8m5wy4atJa7Cq896lOV/fJz nb3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778693309; x=1779298109; 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=k/yihlsgioa3tb/oK9ngpjlNZtNgbvgaG/p//opnvnk=; b=AZPWXfSMxiG42G8ThJ0TXCXEwaovr4TUg0pjSgU4DpBlF2UxJf7ytgJqFhdVccdBmY vxjlby3sImmq1DsY+2DjHqduBvwPCChNdMdGHKHVRhbTKV5ZtgWdA0nvHB12f6N7nk7C x95LmXDoo584goyA/oP4236wDD80/YeEqL74KDOr6bsIlkoXaQbfxJkR/wFWJxPKk+1I eGC6Xf91L00XHewvFsDobqHqubxvaaNrlSJj0eKZrH8c05wMmHUTsNFugVkVSUcMU6MW HavG+XfiNY0oY7Bqh/KYT9CQQD9LBoHtJ9qF02ZyphIM7/2pF5kiOSJBmAgVzWDs/SUm QxuA== X-Forwarded-Encrypted: i=1; AFNElJ/kgsSReYup4ul8sQyFR/MAs3Sd368ARGQOYkdkh+nE1QqFoG6eRRyznvAE3tmfzgRfNyuPVeIqcYiF4gY=@vger.kernel.org X-Gm-Message-State: AOJu0YxPFiqNcpdQWsMXUUSqJp4O8DCl5EKVC11Gppy3ls5QpKx59+VI 6Mhdx5ceSWkEZvRXgpmQcz4DjuvBSwN2r3Id86FhNxZivTQMPYmPaU5dDC4LIOjCk+w= X-Gm-Gg: Acq92OGGeWb9Za1zjbDQBqy1Cl9PFTP6efMGG7fQmFGP4d95U+PO/k0kj841WJQ90F3 Z1COrOEPDig65Z3S+CflkoeDBqoGBtL8dRo8TMj5a0MLCcnxDX5T0TCYHk7K1rA7zFpFEiMMM9f yj7gOSDyebvztUTNQH3KmyBhW4UqO9Ah3CHsMkbDENPQ8LvSlWX69+sR4132iAq6OuBB0R50xFV Xk3Ojteapdte4pWCoE2FQdxEu78MGjoPd+LYif0M/B3kocXiROyflCZpuLlFxJAoKKFs+btJ+rX Cm3beGerEhpdjJArycuGq0zaliTrpCocKc1beWiLrEUhEcys8d5yL/OM2CIKA4F4Elh2vBAFeyh heajVmxmQ167vfeOkvJEqLBAu9/Uk/iFqfCMASjkbibG7oslCjMpHJJX89Xe70GkdC3NksFEjSE 1kpvNpx/3x7DsiR2aoBjyvnw4rMNduHPPau6uEhbrl8qSAMs8lrLecvtO7RkV0/wzUV6Y1XJluP r15eW2rIXUo X-Received: by 2002:a05:6214:4289:b0:8c2:f420:4d60 with SMTP id 6a1803df08f44-8c7bcfed2e8mr70315806d6.38.1778693304138; Wed, 13 May 2026 10:28:24 -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-8c90b2dc4besm1311466d6.32.2026.05.13.10.28.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 10:28:23 -0700 (PDT) Date: Wed, 13 May 2026 13:28:21 -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: On Wed, May 13, 2026 at 05:14:20PM +0000, Brendan Jackman wrote: > On Wed May 13, 2026 at 4:17 PM UTC, Gregory Price wrote: > > > > Why not simply have an unmapped migratetype, for example, and on steal > > you convert it to movable or whatever the preference is? > > Because the fact that only one migratetype currently supports being > unmapped is a temporary happenstance of the guest_memfd usecase. In > general, this needs to support having unmapped variants of ~arbitrary > migratetypes. > Ah I see, that tracks. Thank you for the context. > > > > Unless I'm fundamentally misunderstanding something, the pattern at least > > seems similar. > > Yeah, I actually only noticed that yesterday due to your posts on that > thread! I need to investigate it further. My assumption has always been > that this isn't a general solution because we don't always _have_ a user > address (e.g. for guest_memfd it's important that we can populate the > memory via write(), so there's no user address), but it's pretty likely > I'm missing something there. > Hm. I'm not quite wrapping my head around the TLB issue fully. If there's no kernel direct mapping, and there's no userland mapping, the stale TLB entry comes from... the page formerly being present in the page tables and a stale TLB entry lying about after the page is freed? If that's the case, that sounds more like someone isn't flushing the TLB entry correctly when the page is freed or unmapped (for a transient mermap situation), rather than an issue to be handled by the allocator. I think I just need to spend a little more time understanding the TLB issue. > > The reason we need to do it at the block granularity is that a TLB flush > every time we allocate one of these pages is a performance nonstarter - > that's actually the entire point of this series. If you can afford a TLB > flush per allocation then you don't need __GFP_UNMAPPED for the > guest_memfd usecase, the existing direct map removal series [0] is > already fine. > That tracks. So whatever the case, it seems like you prefer block-granularity map/unmap operations, rather than per-allocation. Do you have numbers on what the cost of map/unmap on a page vs block is? Whatever the case is - you're pushing that cost onto *someone*, so having that data would at least let us know the value of pushing most memory to be unmapped by default rather than the opposite. ~Gregory