tree 1a5c25912bcfda51ca70407af5eacf7263c02cd2
parent d7e6e2fdd7ddafe3a0efd2b7d52b50bd5be6dc24
author Adam Perry <adamperry@fuchsia.infra.roller.google.com> 1743010640 -0700
committer Copybara-Service <copybara-worker@google.com> 1743010738 -0700

[roll] Roll fuchsia [starnix] Prototype a couple flavors of mlock() pinning.

Zircon doesn't have a direct analog for mlock()'s pinning as
of today, but this CL includes two ways to approximate it using
currently available APIs:

1. calling zx_vmar_op_range(ZX_VMAR_ALWAYS_NEED) on the user vmar
2. mapping the backing memory into a different vmar with high priority

(1) still allows the kernel to reclaim pages from the hinted region,
unlock mlock(). It is also "stickier" than mlock(). mlock() is a
property of a mapping -- pages can't be reclaimed while they're in
a locked mapping but once no mapping of that page is locked (either
through unmapping or munlock()) the underlying page is no longer locked.
As I understand it, today it is not possible to remove the ALWAYS_NEED
bit from pages in a VMO without unmapping every VMO that includes that
page in its hierarchy.

Given Zircon's current implementation of memory priorities, (2) fully
protects the pages in the mlock()d range from reclamation, but unlike
Linux it has no effect on the corresponding page table entries for the
mlock()d mappings.

This change lands both approaches under flags to make it possible to
demonstrate their impact on performance and to collect data. It's not
clear whether we want to ship either approach beyond experimentation.

Original-Bug: 297591218

Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1235645
Original-Revision: 203d527e8117eb39ff2f4352abc1af56cf031b6a
GitOrigin-RevId: 9320e597893f07f4923baa87fc31d6c49735523c
Change-Id: Ic7ad4994e3cb4120e9a5dda68a4c4d51afe15a46