Re: [PATCH 01/25] mm/fbatch: remove !CONFIG_SMP special case of folio_activate()

[David Hildenbrand (Arm)]

On 8/24/26 15:52, Hugh Dickins wrote:
> 3.0 commit eb709b0d062e ("mm: batch activate_page() to reduce lock
> contention") brought in an ifdef CONFIG_SMP around activate batching:
> https://lore.kernel.org/linux-mm/20100805140755.501af8a7.akpm@xxxxxxxxxxxxxxxxxxxx/
> shows a sensitivity to bloat that day, not any incompatibility with UP.
> 
> No other batching here has a UP alternative, and it's a bit confusing:
> simplify mm/folio.c a little by removing it now.
> 
> Certainly we can reduce UP bloat (and/or 32-bit bloat) by, say, lowering
> FOLIO_BATCH_SIZE from 31: traditionally 16, 14, 15, then raised to 31 by
> 6.9 commit 9cecde80aae0 ("mm: increase folio batch size"); or by giving
> just the static per-cpu folio batches a type of their own with a smaller
> array size on UP (1? or a little batching worthwhile even on UP?). But
> not right now, it's orthogonal to this series.
> 
> And I suspect that the old ifdef led to lru_activate being placed last,
> whereas it's usually the second most popular fbatch: move it there, to
> match cpu_needs_drain() comment "Check these in order of likelihood that
> they're not zero".
> 

This fits the theme of removing CONFIG_SMP conditionals where they are not
really warranted and cause maintenance overhead.

Let's see if this actually creates real problems we have to worry about.

Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

-- 
Cheers,

David