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 CEB9448EBE4 for ; Wed, 12 Aug 2026 21:26:17 +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=1786569992; cv=none; b=hZo3MfS+Xc84bLcNyULSDHfpdx4KrXO4YrPr36R3kUmtUfIJWU4XEKrVwI2gFFRbndw5StnW6G5f4uv60BFTZzjgZ+GrGdwMx0vmZJt8NQ8vMICyNeiqb+0Gqbdf+LlHoBjXnUbFn2+Qiyb3yJOoexNAs1i4I2mCCQAmf/RGSb0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786569992; c=relaxed/simple; bh=a5HNvp6q0IOTtrToRyBBLWH0f4xDVc1w1gHhPXvYiQA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UIkDFpvzqV1pLln7rcXCYsANgzyjqfo6x5XiRCGwGG1xBsR0HGJq8D1tJrOxgy9zC0w53DPfvVx30gv3edcVaaXrZURihnV6n+o1S4kDYZktozCfZ/MbBmnrwlkCRGGpxdhJy/TdCAb5VvzILQO9nZPyF0bFgQW19/zjIFhg1Ks= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m2YhdIKZ; 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="m2YhdIKZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D29A1F000E9; Wed, 12 Aug 2026 21:26:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786569975; bh=VZ14OE14W6R2szqcv6OQ5JAU2OtnvGYenTEQKteSjqE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=m2YhdIKZxPGAsE+fyk34oqW883dfKuKiM1yKE0mJVGS2lQwD8/OrByY100MokqwXa Ui8q91vgTqLDqi8KTyyPp/zj4LtPF3tMAmTdQmlgVM4r2GGtVrbK6rXtlQsBOLEQcr RHOHOISwF/eSVkuxn5eQiPiLv7A5Q2TcngViLvRnwiNdpYYUEKXsmPRw9ChiAUK3Xo c7L+zq85vvflb41d3lsfvmBH25k84bhHT6sG+tn/T5x+BOcl75Dpg2kND8t3sVPZps dJ1vy6+ueDy8OVBjVZ0hGy2fWhqlsQHEr2Vm5E15Yd5ApSjex3wTitm+7p+n7cUq72 S85UkV9Tfkv3g== Date: Wed, 12 Aug 2026 21:26:12 +0000 From: Yosry Ahmed To: Brendan Jackman , 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: <20260726-page_alloc-unmapped-v3-21-6f5729aa9832@google.com> [..] > 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. 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). 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. 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. > + if (!page) > + return NULL; > + > } while (check_new_pages(page, order)); > > /*