From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-214.mta1.migadu.com [95.215.58.214]) (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 3A45E327BFA for ; Sat, 15 Aug 2026 14:43:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.214 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786805015; cv=none; b=JSS5vbvM8dXJioWdou3+KUHU9S5Ul1O8hTw6TC3BF78T0m79/uJ4iRwkvxZ3p8PXn5bogajMx1W1BWVHZIvf3y3tHU7IpKjlH/Ke2dbmOPqbipAeyrkFGoR58pW0e2JBPokfVX6EoTyNFjNRXUNY/grebaYUQBagoP1qcHo3b30= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786805015; c=relaxed/simple; bh=4//uIXJEQ+puCtDj34Ag6s3cT0uGXLeBX5VN/A05+2w=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=PwyOoe+LlcsN9qWsnDtL8Rd9m7a36SFHzlQ6gQP/bkaRrZKj9/70odBIGM9G3zTs5h8C9yHnQTT6pjxGg2wtNZnSNFRab11A8CwqgO9r4Xp01UFIlrw5f9ywPx7zXyry66vI115ioMc9lEZUKH+Ov9KAqwbcF8W45mazwrP6SQI= 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=PjBcCm2v; arc=none smtp.client-ip=95.215.58.214 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="PjBcCm2v" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=4//uIXJEQ+puCtDj34Ag6s3cT0uGXLeBX5VN/A05+2w=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786805010; v=1; x=1787409810; b=PjBcCm2vYXhQph+sYLh/Wf58HKQOfEadJOeYXQmZbEZLcZMzMNo3CSJGnMRHVV/8w8yciwO1 NxZd6dRoo503Pu5Wk4N4SKTt+dIpOEMko/wgsPFcED/M5fKN9/oPTf00fJibABLeVx61kF3lJI5 VFUlwgzDBZAM/oZB4YElfzcY= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (77.97.51.77) by smtp.migadu.com with ESMTPS id 82a6b59325fd5af9; Sat, 15 Aug 2026 14:43:19 +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: Sat, 15 Aug 2026 15:43:18 +0100 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 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 *zo= ne, >> unsigned int order, unsigned int alloc_flags, >> @@ -3433,13 +3580,15 @@ struct page *rmqueue_buddy(struct zone *preferre= d_zone, struct zone *zone, >> */ >> if (!page && (alloc_flags & (ALLOC_OOM|ALLOC_HARDER))) >> page =3D __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 =3D __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? > 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. > 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. > 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. >> + if (!page) >> + return NULL; >> + >> } while (check_new_pages(page, order)); >> =20 >> /*