Re: [LSF/MM/BPF TOPIC] Non-lru page migration in a memdesc world

[David Hildenbrand <david@redhat.com>]

On 07.01.25 17:11, David Hildenbrand wrote:
> Hi,
> 
> one item on my todo list is making PageOffline pages to stop using
> "struct page" members except page->type and 1/2 flags, to prepare them
> for the memdesc future, to avoid unnecessary atomics, and to resolve
> some (so-far) theoretical issues with temporary speculative references.
> 
> For example, the page->_refcount will always be 0 (frozen) for
> PageOffline pages, and they will get allocated/freed similar to how we
> allocate/free frozen pages for slab already. Once we move the refcount
> into "struct folio", they will not have a refcount at all anymore.
> 
> One complication is balloon compaction: we allow for migrating
> PageOffline pages allocated in some memory ballooning implementations
> such as virtio-balloon.
> 
> For that, we use the "non-lru page migration" framework and in that
> process we make use of ... way to many members of "struct page"/"struct
> folio" and rely on the refcount not being 0. For example, we certainly
> don't want to allocate memdescs for PageOffline pages just so some of
> them can be migrated.
> 
> While we converted non-lru page migration to work on folios (i.e.,
> folio_movable_ops()) these things are not actually "folios" in the
> future, they can have different memdescs.
> 
> So, how can we migrate non-lru things that are not folios while not
> relying on "struct folio" members, with minimal/no metadata overhead?
> 
> I have some ideas, but no complete solution yet; input about the
> requirements of other non-lru page migration use cases besides
> PageOffline will be interesting.
> 
> ... and maybe, we have other non-folio things we'd want to migrate, and
> want to be prepared to handle them as well? (hint: leaf page tables?)
> 

Slides from today:

https://drive.google.com/file/d/1NIjjwVAonz9WWIoJZ0nh71ovMfSjfqFc/view?usp=sharing

-- 
Cheers,

David / dhildenb