Re: [PATCH v4 16/21] mm/mm_init: simplify deferred_free_pages() migratetype init

On Mon, Jul 27, 2026 at 11:43:31AM +0800, Muchun Song wrote:
> 
> 
> > On Jul 27, 2026, at 11:25, Andrew Morton <[email protected]> wrote:
> > 
> > On Sun, 26 Jul 2026 13:16:54 +0300 Mike Rapoport <[email protected]> wrote:
> > 
> >> On Sat, Jul 25, 2026 at 07:21:16PM +0200, Pratyush Yadav wrote:
> >>> From: Muchun Song <[email protected]>
> >>> 
> >>> deferred_free_pages() open-codes two loops to initialize the pageblock
> >>> migratetype for a range of pages.
> >>> 
> >>> Replace them with pageblock_migratetype_init_range() to remove the
> >>> duplication and make the code clearer (Note that deferred_free_pages() may
> >>> be called from atomic context).
> >>> 
> >>> Link: https://lore.kernel.org/[email protected]
> >>> Signed-off-by: Muchun Song <[email protected]>
> >>> Acked-by: Mike Rapoport (Microsoft) <[email protected]>
> >>> Acked-by: Oscar Salvador <[email protected]>
> >>> Signed-off-by: Pratyush Yadav (Google) <[email protected]>
> >>> ---
> >>> 
> >>> Notes:
> >>>    This patch is taken from Muchun's series [0]. The patch as of today is
> >>>    in mm-unstable.
> >> 
> >> @Andrew,
> >> 
> >> It looks like it'll take some time for this patch to get into mm-stable so
> >> we can't base this work on a branch in the mm tree :(
> > 
> > I didn't know anyone was using mm-stable :(

Maybe nobody uses it because it's not really stable? ;-)
 
> > Series is adequately reviewed and is near head-of-queue so I can move
> > it into mm-stable a few days hence if that helps?
> > 
> >> I'd like to expose the KHO scratch extension to linux-next ASAP so I'm
> >> inclined to take this patch as a part of this series and live for a while
> >> with a duplicated commit in linux-next. Once this patch would be in
> >> mm-stable we can rebase kho-scratch work on top of mm-stable and hopefully
> >> there will be enough time for it to live in linux-next so that Linus won't
> >> get angry at us :) 
> >> 
> >> How does that sound to you?
> > 
> > That's fine - let me know what you choose to do and I'll adapt to it.
> > 
> > An unknown (to me) is whether Muchun's series "mm: Refactor bootmem
> > gigantic hugepage allocation, v4" still works with this patch removed.  Everything
> > applies OK for what that's worth.
> 
> Hi Andrew,
> 
> I'd like to confirm that this is a completely independent cleanup patch,
> so it can be merged on its own.

That's great, thanks for confirming!

Then I think the easiest would be to take "mm/mm_init: simplify
deferred_free_pages() migratetype init" via liveupdate tree.
 
-- 
Sincerely yours,
Mike.