[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <43ab8a08-b577-4e6d-8920-1761ffbc01fc@redhat.com>
Date: Tue, 20 May 2025 10:58:11 +0200
From: David Hildenbrand <david@...hat.com>
To: Zi Yan <ziy@...dia.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, Oscar Salvador <osalvador@...e.de>,
Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
Brendan Jackman <jackmanb@...gle.com>, Richard Chang
<richardycc@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/4] Make MIGRATE_ISOLATE a standalone bit
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
Powered by blists - more mailing lists