Messages in this thread |  | | Date | Tue, 20 May 2025 10:58:11 +0200 | | Subject | Re: [PATCH v4 0/4] Make MIGRATE_ISOLATE a standalone bit | | From | David Hildenbrand <> |
| |
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
|  |