From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9258817B425 for ; Tue, 18 Aug 2026 00:49:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787014176; cv=none; b=pseO0+XuARIRpI7o+ovWnHJz4Fk9SYTUyT/wJoQEQA2MptwHHy2/wzjiC9tQ7RzNfxwQPNEwFU+6CFe/I8DQMS5imLqMejn9Koa6KJ4odeX4IWg4FHomEzhthV+yrDHz0lasaT5syWsk+2yrL/5bNcNGhB02LL65YkGUtwpo47U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787014176; c=relaxed/simple; bh=dzJ1Eoeki5zJhuscW66Hh+lrLRviHVZMaPJmmLIVTVQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NW73QikNkcPugVHs/wBH2KzwLT3e5QULgI87G8gqUTU5zSwq3e1mVHtVDUc/M6al1crSLOflYrjG2/whLeA/+mfH9YFsMB5JJwDuD2/OZPslBR91h2j3+lcyU6q+HDZqoi7nFv/M+i/iGJXhGWzZWoVeBwfZ5aey/vshTkSuUb4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d1DrblM9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="d1DrblM9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 611391F000E9; Tue, 18 Aug 2026 00:49:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787014175; bh=ClssdD91oq/MStCE+y61oU2BRmlqfB32tzgOC4Y7hqg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=d1DrblM9L1RfFyBf5bUrSxDMsRf+HElRT4kC8IeYcvkT/zoJrLYvtavyFy06hjGBz UNR7SuVQ/5buJCqkwKcb8ZfuL9eynueKEWfpQoKcrFz4R23NpSVzIGfyXOFvmMhK0c 70RcXww3NH4HutBf4jd3Rn+6wsc3/f7odF+ZGjO7U/5kFThgp0SnYmWLfk+V4GVRfn xFAcEWahrFxTUXdKW4uoqWyNxyyvqOjo9caGfW1jR/Tfy31if8nJRbzEklGNY3rYbT eYCpM7sMJ4EDXArPIr3ESoor6yxjq5DeXsM5EtRxzaBSjazHpMOE+/jz562nCe8P7O WWLUeO7qv1M2g== Date: Tue, 18 Aug 2026 00:49:33 +0000 From: Yosry Ahmed To: 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 , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, patrick.roy@linux.dev, "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 Message-ID: References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-21-6f5729aa9832@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 Sat, Aug 15, 2026 at 03:43:18PM +0100, Brendan Jackman wrote: > On Wed Aug 12, 2026 at 10:26 PM BST, Yosry Ahmed wrote: > > [..] > >> static __always_inline > >> struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone, > >> unsigned int order, unsigned int alloc_flags, > >> @@ -3433,13 +3580,15 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone, > >> */ > >> if (!page && (alloc_flags & (ALLOC_OOM|ALLOC_HARDER))) > >> page = __rmqueue_smallest(zone, order, ft_high); > >> - > >> - if (!page) { > >> - spin_unlock_irqrestore(&zone->lock, flags); > >> - return NULL; > >> - } > >> } > >> spin_unlock_irqrestore(&zone->lock, flags); > >> + > >> + /* Try changing direct map, now we've released the zone lock */ > >> + if (!page) > >> + page = __rmqueue_direct_map(zone, order, alloc_flags, freetype); > > > > Is it intentional that this is called outside __rmqueue() and doesn't > > cover pcplists refills through rmqueue_bulk()? > > > > IIUC, we will never change a pageblock to unmapped to refill the > > pcplists, so the unmapped pcplists can get filled in two ways: > > (a) When unmapped pages are freed. > > (b) When a pageblock is converted here (in rmqueue_buddy()), if the > > allocation only consumes part of it, the new allocation might move > > the rest into the pcplist through rmqueue_bulk(). > > > > Does this mean that unmapped pcplists are less effective in serving > > allocations? There is a tradeoff here because converting a pageblock to > > unmapped is expensive, so maybe this is the right choice to make, I am > > just wondering if this was intentional and/or if we tried it a different > > way. > > Yeah I think this is all aligned with how I envisaged this working. I > have been assuming that changing pageblocks only happens: > > 1. When botting / changing between different kinds of workload. > > 2. When the system is quite distressed by memory pressure. > > I think in both cases, proactively flipping a block just to refill > pcplists is unhelpful? I guess it depends on what context we refill in the pcplists in. If we are already holding the zone lock it might be worth a refill to avoid holding it again to do it later? I am not sure. We can probably punt on this until we have numbers. > > > Actuall, THPs are not covered by scenario (b) above if the pageblock > > size is the same as THP size, as the converted THPs are always consumed > > by the allocation, so the THP pcplist will only be filled when THPs are > > freed. > > > > I wonder if this would cause a problem for THP-heavy workloads (e.g. > > guest_memfd using THP, or any THP usage with ASI). > > And again it doesn't feel right to proactively flip a block just to > create a pcplist. The cost of a pcplist miss is basically a bit of > cacheline contention while the cost of flipping a block is pretty high, > it seems well worth risking the former to avoid the latter. Zone lock contention can be a big problem. But yeah we probably shouldn't make a decision without some numbers. > > > The other thing (that I probably mentioned elsewhere) is that kcompactd > > does not produce unmapped pageblocks, so it seems like THP allocations > > will mostly hit this code path and convert a pageblock to unmapped. > > Yeah, I think making kcompactd produce unmapped blocks is a nice > standalone optimisation series and it can probably wait until someone > has a workload they can share the performance improvements from. Yup. > > > Actually, if we do bulk conversion to unmapped (e.g. in kcompactd) we > > could batch the TLB shootdowns as well, but that should probably be done > > separately. > > Oh, that's a good point though, coz that would also interact nicely with > pcplists. In theory we could allocate several contiguous pageblocks, > flip them with a single amortised flush, and then use that to refill > pcplists. But yeah this still feels like far future optimisations if and > when we actually knew it helped. Agreed.