On 30.11.23 18:57, David Hildenbrand wrote:
On 30.11.23 18:46, Peter Xu wrote:
On Thu, Nov 30, 2023 at 05:54:26PM +0100, David Hildenbrand wrote:
But likely we want THP support here. Because for hugetlb, one would actually
have to instruct the kernel which size to use, like we do for memfd with
hugetlb.
I doubt it, as VM can still leverage larger sizes if possible?
What do you doubt? I am talking about the current implementation and
expected semantics of KVM_GUEST_MEMFD_ALLOW_HUGEPAGE.
I looked at the kernel implementation, and it simply allocates a
PMD-sized folio and puts it into the pagecache. So hugetlb is not involved.
That raises various questions:
1) What are the semantics if we ever allow migrating/compacting such
folios. Would we allow split them into smaller pages when required
(or compact into larger)? What happens when we would partially zap
them (fallocate?)right now? IOW, do they behave like THP, and do we
want them to behave like THP?
2) If they behave like THP, wow would we able to compact them into
bigger pages? khugepaged only works on VMAs IIRC.
3) How would you allocate gigantic pages if not by the help of hugetlb
and reserved pools? At least as of today, runtime allocation of
gigantic pages is extremely unreliable and compaction into gigantic
pages does not work. So gigantic pages would be something for that
far distant future.
4) cont-pte-sizes folios?
Maybe it's all clarified already, in that case I'd appreciate a pointer.
Looking at the current code, it looks like it behaves like shmem thp,
just without any way to collapse afterwards (unless I am missing something).
--
Cheers,
David / dhildenb
