Message-ID: <8ce464e2-1447-4e60-8abe-f4ddd511d7a7@redhat.com>
Date: Wed, 14 May 2025 16:12:52 +0200
From: David Hildenbrand <david@...hat.com>
To: Zi Yan <ziy@...dia.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 virtualization@...ts.linux.dev, "Michael S. Tsirkin" <mst@...hat.com>,
 Jason Wang <jasowang@...hat.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
 Eugenio Pérez <eperezma@...hat.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Oscar Salvador
 <osalvador@...e.de>, Vlastimil Babka <vbabka@...e.cz>,
 Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
 Brendan Jackman <jackmanb@...gle.com>, Johannes Weiner <hannes@...xchg.org>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>
Subject: Re: [PATCH v1 0/2] mm/memory_hotplug: introduce and use
 PG_offline_skippable

On 14.05.25 15:45, Zi Yan wrote:
> On 14 May 2025, at 7:15, David Hildenbrand wrote:
> 
>> This is a requirement for making PageOffline pages not have a refcount
>> in the long future ("frozen"), and for reworking non-folio page migration
>> in the near future.
>>
>> I have patches mostly ready to go to handle the latter. For turning all
>> PageOffline() pages frozen, the non-folio page migration and memory
>> ballooning drivers will have to be reworked first, to no longer rely on
>> the refcount of PageOffline pages.
>>
>> Introduce PG_offline_skippable that only applies to PageOffline() pages --
>> of course, reusing one of the existing PG_ flags for now -- and convert
>> virtio-mem to make use of the new way: to allow for skipping PageOffline
>> pages during memory offlining, treating them as if they would not be
>> allocated.
> 

Thanks for taking a look!

> IIUC, based on Documentation/admin-guide/mm/memory-hotplug.rst,
> to offline a page, the page first needs to be set PageOffline() to be

PageOffline is not mentioned in there. :)

Note that PageOffline() is a bit confusing because it's "Memory block 
online but page is logically offline (e.g., has a memmap that can be 
touched, but the page content should not be touched)".

(memory block offline -> all pages offline and have effectively no state 
because the memmap is stale)

> removed from page allocator.

Usually, all pages are freed back to the buddy (isolated pageblock -> 
put onto the isolated list). Memory offlining code can then simply grab 
these "free" pages from the buddy -- no PageOffline involved.

If something fails during memory offlining, these isolated pages are 
simply put back on the appropriate migratetype list and become ordinary 
free pages that can be allocated immediately.

Some PageOffline pages can be migrated using the non-folio migration: 
this is done for memory ballooning (memory comapction). As they get 
migrated, they are freed back to the buddy, PageOffline() is cleared -- 
they become PageBuddy() -- and the above applies.

Other PageOffline pages can be skipped during memory offlining 
(virtio-mem use case, what we are doing her). We don't want them to ever 
go through the buddy, especially because if memory offlining fails they 
must definitely not be treated like free pages that can be allocated 
immediately.

Next, the page is removed from its memory
> block. When will PG_offline_skippable be used? The second phase when
> the page is being removed from its memory block?

PG_offline_skippable is used during memory offlining, while we look for 
any pages that are not PageBuddy (... or hwpoisoned ...), to migrate 
them off the memory so they get converted to PageBuddy.

PageOffline + PageOfflineSkippable are checked on that phase, such that 
they don't require any migration.

-- 
Cheers,

David / dhildenb

Powered by blists - more mailing lists