Re: [PATCH v4 0/4] Make MIGRATE_ISOLATE a standalone bit

[David Hildenbrand <david@redhat.com>]

On 19.05.25 16:35, Zi Yan wrote:
> On 19 May 2025, at 10:15, David Hildenbrand wrote:
> 
>> On 18.05.25 02:20, Zi Yan wrote:
>>> On 17 May 2025, at 16:26, Vlastimil Babka wrote:
>>>
>>>> On 5/9/25 22:01, Zi Yan wrote:
>>>>> Hi David and Oscar,
>>>>>
>>>>> Can you take a look at Patch 2, which changes how online_pages() set
>>>>> online pageblock migratetypes? It used to first set all pageblocks to
>>>>> MIGRATE_ISOLATE, then let undo_isolate_page_range() move the pageblocks
>>>>> to MIGRATE_MOVABLE. After MIGRATE_ISOLATE becomes a standalone bit, all
>>>>> online pageblocks need to have a migratetype other than MIGRATE_ISOLATE.
>>>>> Let me know if there is any issue with my changes.
>>>>>
>>>>> Hi Johannes,
>>>>>
>>>>> Patch 2 now have set_pageblock_migratetype() not accepting
>>>>> MIGRATE_ISOLATE. I think it makes code better. Thank you for the great
>>>>> feedback.
>>>>>
>>>>> Hi all,
>>>>>
>>>>> This patchset moves MIGRATE_ISOLATE to a standalone bit to avoid
>>>>> being overwritten during pageblock isolation process. Currently,
>>>>> MIGRATE_ISOLATE is part of enum migratetype (in include/linux/mmzone.h),
>>>>> thus, setting a pageblock to MIGRATE_ISOLATE overwrites its original
>>>>> migratetype. This causes pageblock migratetype loss during
>>>>> alloc_contig_range() and memory offline, especially when the process
>>>>> fails due to a failed pageblock isolation and the code tries to undo the
>>>>> finished pageblock isolations.
>>>>
>>>> Seems mostly fine to me, just sent suggestion for 4/4.
>>>
>>> Thanks.
>>>
>>>> I was kinda hoping that MIGRATE_ISOLATE could stop being a migratetype. But
>>>> I also see that it's useful for it to be because then it means it has the
>>>> freelists in the buddy allocator, can work via __move_freepages_block() etc.
>>>
>>> Yeah, I wanted to remove MIGRATE_ISOLATE from migratetype too, but there
>>> is a MIGRATE_ISOLATE freelist and /proc/pagetypeinfo also shows isolated
>>> free pages.
>>
>> The latter, we can likely fake.
>>
>> Is there a reasonable way to remove MIGRATE_ISOLATE completely?
>>
>> Of course, we could simply duplicate the page lists (one set for isolated, one set for !isolated), or keep it as is and simply have a
> 
> That could work. It will change vmcore layout and I wonder if that is a concern
> or not.

Not really. makedumpfile will have to implement support for the new 
layout as it adds support for the new kernel version.

> 
>> separate one that we separate out. So, we could have a migratetype+isolated pair instead.
> 
> What do you mean by a migratetype+isolate pair?

If MIGRATE_ISOLATE no longer exists, relevant code would have to pass 
migratetype+isolated (essentially, what you did in 
init_pageblock_migratetype ).


E.g., we could pass around a "pageblock_info" (or however we call it, 
using a different type than a bare migratetype) from which we can easily 
extract the migratetype and the isolated state.


E.g., init_pageblock_migratetype() could then become

struct pageblock_info pb_info = {
	.migratetype = MIGRATE_MOVABLE,
	.isolated = true,
}
init_pageblock_info(page, pb_info);

So, we'd decouple the migratetype we pass around from the "isolated" 
state. Whoever needs the "isolated" state in addition to the migratetype 
should use get_pageblock_info().

When adding to lists, we can decide what to do based on that information.

> 
>>
>> Just a thought, did not look into all the ugly details.
> 
> Another thought is that maybe caller should keep the isolated free pages instead
> to make it actually isolated.

You mean, not adding them to a list at all in the buddy? I think the 
problem is that if a page gets freed while the pageblock is isolated, it 
cannot get added to the list of an owner easily.

-- 
Cheers,

David / dhildenb