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

Muchun Song
2026-04-14T03:04:55Z

> On Apr 14, 2026, at 02:50, David Hildenbrand (Arm) <david@kernel.org> wrote:
>
> On 4/13/26 15:57, Muchun Song wrote:
>>
>>
>>> On Apr 13, 2026, at 21:28, Mike Rapoport <rppt@kernel.org> 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