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

[Muchun Song]

> On Jul 27, 2026, at 11:25, Andrew Morton <akpm at linux-foundation.org> wrote:
> 
> On Sun, 26 Jul 2026 13:16:54 +0300 Mike Rapoport <rppt at kernel.org> wrote:
> 
>> On Sat, Jul 25, 2026 at 07:21:16PM +0200, Pratyush Yadav wrote:
>>> From: Muchun Song <songmuchun at bytedance.com>
>>> 
>>> 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/20260612035903.2468601-6-songmuchun@bytedance.com
>>> Signed-off-by: Muchun Song <songmuchun at bytedance.com>
>>> Acked-by: Mike Rapoport (Microsoft) <rppt at kernel.org>
>>> Acked-by: Oscar Salvador <osalvador at suse.de>
>>> Signed-off-by: Pratyush Yadav (Google) <pratyush at kernel.org>
>>> ---
>>> 
>>> 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 :(
> 
> 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.

Thanks.