Re: [PATCH 06/49] mm/mm_init: fix uninitialized pageblock migratetype for ZONE_DEVICE compound pages
From: David Hildenbrand (Arm)
Date: Mon Apr 13 2026 - 14:50:58 EST
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.
--
Cheers,
David