Re: [PATCH 06/49] mm/mm_init: fix uninitialized pageblock migratetype for ZONE_DEVICE compound pages

[Muchun Song]

> On Apr 14, 2026, at 02:50, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> 
> On 4/13/26 15:57, Muchun Song wrote:
>> 
>> 
>>> On Apr 13, 2026, at 21:28, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
>>> 
>>> On Mon, Apr 13, 2026 at 06:07:44PM +0800, Muchun Song wrote:
>>>> 
>>>> 
>>>> 
>>>> Of course not.
>>>> 
>>>> 
>>>> There are indeed many more cond_resched() than before, but I don’t have a
>>>> concise way to write it, so I took the easy way out.
>>>> 
>>>> How about:
>>>> 
>>>> diff --git a/mm/mm_init.c b/mm/mm_init.c
>>>> index 2d680636b67a..d13a2577c4c3 100644
>>>> --- a/mm/mm_init.c
>>>> +++ b/mm/mm_init.c
>>>> @@ -683,7 +683,8 @@ static __meminit void pageblock_migratetype_init_range(unsigned long pfn,
>>>> 
>>>>       for (pfn = pageblock_align(pfn); pfn < end; pfn += pageblock_nr_pages) {
>>>>               init_pageblock_migratetype(pfn_to_page(pfn), migratetype, isolate);
>>>> -               cond_resched();
>>>> +               if ((pfn & (pageblock_nr_pages * 512 - 1)) == 0)
>>>> +                       cond_resched();
>>> 
>>> TBH, I don't know if 512 is the right number :)
>> 
>> I picked this number out of thin air. I’m not sure as well.
>> 
>>> 
>>> pageblock boundary was a convenient point to have cond_resched() along with
>>> setting the migrate type.
>>> 
>>> Here we might be able to squeeze more iterations between subsequent
>>> cond_resched() calls.
>> 
>> Choosing an appropriate number is indeed difficult. We need to consider
>> both unnecessary cond_resched() calls and scheduling latency, and the
>> specific value also depends on the current CPU performance. At the very least,
>> I find it hard to choose a correct value. Since we all agree it should be larger
>> than 512, why not just pick 1024? I can't think of a good evaluation criterion
>> or selection method either.
> 
> I think in some other code we just use section boundaries.

It is a good suggestion. I'll do that.

Thanks.

> 
> -- 
> Cheers,
> 
> David