Re: [PATCH v2 17/26] mm/fbatch: no lru_cache_disable() in __alloc_contig_migrate_range()

[Alen Karnil <alen.karnil@ideasonboard.com>]

Hi Hugh,

I've come across your series because of a usecase I have, namely this patch.

Not to bore you with details, I got an IMX8MPlus with some cameras.
Due to the cameras (and other associated HW), it ends up allocating 
multiple framebuffers using CMA (currently 16 per camera)
which is quite slow (~200ms for a single camera).

I've spent some time profiling and found that the biggest
stall is when lru_cache_disable() is called. Just applying the patch on 
its own, I saw greatly improved performance (cutting the delay almost 5x).

This is on a 7.2 kernel.

On 09/09/2026 11:16, Hugh Dickins wrote:
> Remove lru_cache_disable() from __alloc_contig_migrate_range(). It does
> not now benefit from lru_add_drain_all() first; and gains little benefit
> from invalidating buffer head LRUs first, since 5.0 commit 80409c65e2c6
> ("mm: migrate: make buffer_migrate_page_norefs() actually succeed").
> 
> This will be more controversial. lru_cache_disable()+lru_cache_enable()
> were brought in for CMA page migration, see 5.13 commit d479960e44f2
> ("mm: disable LRU pagevec during the migration temporarily") through
> 8cc621d2f45d ("mm: fs: invalidate BH LRU during page migration") - I
> guess the testing there must have been on a 4.19-based Android kernel,
> without 5.0's buffer_migrate_page_norefs().
> 
> It's possible that invalidating BH LRUs perhaps 0 times, perhaps N
> times, will average out worse than invalidating 1 time and stopping
> everyone else; or that folio_test_clear_lru() failures manifest more
> than before (note how folio migration has retries on raised refcount,
> but isolate_migratepages_block() no retry on failed test_clear_lru).
> But let's give this a try and look out for regressions.
> 
> Don't delete lru_cache_disable() yet: leaving stale folio pointers in
> the per-cpu fbatches, with folio_try_get() yet to come on them, would be
> bad for memory hotremoval: the lru_cache_disable() in offline_pages()
> protects from that.
>
Can the patch stand on its own?> Signed-off-by: Hugh Dickins 
<hughd@google.com>
> ---
>   mm/page_alloc.c | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 12fac9084c48..3e085a25a776 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7147,8 +7147,6 @@ static int __alloc_contig_migrate_range(struct compact_control *cc,
>   		.reason = MR_CONTIG_RANGE,
>   	};
>   
> -	lru_cache_disable();
> -
>   	while (pfn < end || !list_empty(&cc->migratepages)) {
>   		if (fatal_signal_pending(current)) {
>   			ret = -EINTR;
> @@ -7182,7 +7180,6 @@ static int __alloc_contig_migrate_range(struct compact_control *cc,
>   			break;
>   	}
>   
> -	lru_cache_enable();
>   	if (ret < 0) {
>   		if (!(cc->gfp_mask & __GFP_NOWARN) && ret == -EBUSY)
>   			alloc_contig_dump_pages(&cc->migratepages);

-- 
Thanks,
Alen Karnil