On 10/09/2025 22:37, James Houghton wrote:
On Tue, Sep 2, 2025 at 4:20 AM Kalyazin, Nikita kalyazin@amazon.co.uk wrote:
[ based on kvm/next ]
Implement guest_memfd allocation and population via the write syscall. This is useful in non-CoCo use cases where the host can access guest memory. Even though the same can also be achieved via userspace mapping and memcpying from userspace, write provides a more performant option because it does not need to set page tables and it does not cause a page fault for every page like memcpy would. Note that memcpy cannot be accelerated via MADV_POPULATE_WRITE as it is not supported by guest_memfd and relies on GUP.
Populating 512MiB of guest_memfd on a x86 machine:
- via memcpy: 436 ms
- via write: 202 ms (-54%)
Silly question: can you remind me why this speed-up is important?
The speed-up is important for the Firecracker use case [1] because it is likely for the population to stand on the hot path of the snapshot restore process. Even though we aim to prepopulate the guest memory before it gets accessed by the guest, for large VMs the guest has a good chance to hit a page that isn't yet populated triggering on-demand fault handling which is much slower, and we'd like to avoid those as much as we can.
[1]: https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotti...
Also, I think we can get the same effect as MADV_POPULATE_WRITE just by making a second VMA for the memory file and reading the first byte of each page. Is that a viable strategy for your use case?
If I understand correctly what you mean, it doesn't look much different from the memcpy option I mention above. All those one-byte read accesses will trigger user mapping faults for every page, and they are quite slow. write() allows to avoid them completely.
Seems fine to me to allow write() for guest_memfd anyway. :)
Glad to hear that!