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. Signed-off-by: Hugh Dickins --- mm/page_alloc.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 083cbcb5bdde..96ab51b78a5f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7135,8 +7135,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; @@ -7170,7 +7168,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); -- 2.51.0