Re: [PATCH v3] mm/page_alloc: avoid direct compaction for costly __GFP_NORETRY allocations

[Christoph Hellwig <hch@infradead.org>]

On Thu, Aug 27, 2026 at 09:21:00AM +0000, Salvatore Dipietro wrote:
> 
> On Wed, Jul 22, 2026 at 02:35:00PM +0200, Vlastimil Babka (SUSE) wrote:
> > AFAICS both your v3 and the implemented Johannes' suggestion effectively
> > make all the compact_first logic dead code - at least for the intended THP
> > use case based on costly_order. It will only continue to do something for
> > the non-movable order>0  case. So that's a significant change which will not
> > show up in your results, but might affect other workloads (I'd expect mainly
> > by having fewer THPs).
> 
> Right - the change above modifies THP allocation requests as well. So instead
> of applying it to every costly __GFP_NORETRY allocation, I restrict it to
> callers that do not ask for __GFP_THISNODE. That leaves the local-node THP
> attempt untouched: the same bit pair is already tested further down the function 
> to bail out of the compact_first block (page_alloc.c:4899), and alloc_pages_mpol()
> sets both flags on the local-node-first attempt (mempolicy.c:2476-2478).
> 
> I tested this with my PostgreSQL workload on kernel v7.2-rc7 and results look good:
> 
> Baseline:       70,735 tps
> This version:  144,670 tps  (145,280 / 144,037 / 144,694)  +104.5%

This looks really nice.  Can you turn this into a formal patch?