Re: [PATCH v3 1/4] mm/page_isolation: make page isolation a standalone bit.

[Zi Yan]

On 8 May 2025, at 21:33, Zi Yan wrote:

> On 8 May 2025, at 16:53, Zi Yan wrote:
>
>> On 8 May 2025, at 16:46, Johannes Weiner wrote:
>>
>>> On Thu, May 08, 2025 at 03:17:05PM -0400, Zi Yan wrote:
>>>>
>>>>>>> @@ -426,7 +460,12 @@ void set_pageblock_migratetype(struct page *page, int migratetype)
>>>>>>>  		     migratetype < MIGRATE_PCPTYPES))
>>>>>>>  		migratetype = MIGRATE_UNMOVABLE;
>>>>>>>
>>>>>>> -	set_pfnblock_flags_mask(page, (unsigned long)migratetype,
>>>>>>> +#ifdef CONFIG_MEMORY_ISOLATION
>>>>>>> +	if (migratetype == MIGRATE_ISOLATE)
>>>>>>> +		set_pageblock_isolate(page);
>>>>>>
>>>>>> Are there paths actually doing this after the second patch?
>>>>>>
>>>>>> There are many instances that want to *read* the migratetype or
>>>>>> MIGRATE_ISOLATE, but only isolation code should be manipulating that
>>>>>> bit through the dedicated set/toggle_pageblock_isolate API.
>>>>>>
>>>>>> If there isn't one, it might be good to enforce this with a VM_WARN
>>>>>> instead.
>>>>>
>>>>> I checked all set_pageblock_migratetype() callers and do not see
>>>>> one using it for pageblock isolation. Let me replace the code
>>>>> with a VM_WARN and add a comment to tell users to use dedicated
>>>>> pageblock isolation APIs.
>>>>>
>>>>
>>>> Actually, move_freepages_block_isolate() calls __move_freepages_block()
>>>> to move free pages to MIGRATE_ISOLATE pageblock and
>>>> set_pageblock_migratetype() is used inside __move_freepages_block().
>>>> So the branch has to stay. Will use the suggestion below.
>>>
>>> Ah, good catch. But looking at the callers, it's:
>>>
>>> move_freepages_block()
>>> move_freepages_block_isolate()
>>> try_to_claim_block()
>>>
>>> The last one would benefit from having the set_pageblock_migratetype()
>>> there explicitly, as this is what this function is supposed to do. It
>>> also should never set the isolation bit.
>>>
>>> move_freepages_block_isolate() has two set_pageblock_migratetype()
>>> calls already. And after the series, it should only manipulate the
>>> isolate bit, not change the actual migratetype anymore, right?
>>>
>>> Maybe it makes the most sense to move it into the three callers?
>>>
>>> And then fortify set_pageblock_migratetype() after all.
>>
>> Sounds good to me. Let me update my fixups.
>
> Hmm, hit another roadblock. In online_pages() from mm/memory_hotplug.c,
> move_pfn_range_to_zone(MIGRATE_ISOLATE) calls memmap_init_range(),
> which uses set_pageblock_migratetype(MIGRATE_ISOLATE).
>
> I could use set_pageblock_isolate() in memmap_init_range(), but
> that requires move set_pageblock_isolate() out of mm/page_isolation.c.
> The change might be too substantial for a fixup.
>
> I also would like to get some opinion from David on this. So I am
> holding this fixup and will send it out as a separate patch when
> I get more information.

Hi David,

I have some concern regarding online_pages() calling
move_pfn_range_to_zone(MIGRATE_ISOLATE) code path after my patchset.
During the process, all pageblocks are initialized to MIGRATE_ISOLATE,
then undo_isolate_page_range() is called to unisolate all pageblocks.
That means these pageblocks do not have proper migratetype, since
they are not set to any type other than MIGRATE_ISOLATE.

Maybe the code should be changed to

move_pfn_range_to_zone(zone, pfn, nr_pages, NULL, MIGRATE_MOVABLE);
start_isolate_page_range(pfn, pfn + nr_pages, ISOLATE_MODE_NONE, 0);
...
undo_isolate_page_range(pfn, pfn + nr_pages);

so that these pageblocks have MIGRATE_MOVABLE type.

--
Best Regards,
Yan, Zi