| commit | 0e019b1a9e487b2711630afc502cd81da0e18e7f | [log] [tgz] |
|---|---|---|
| author | Adam Perry <adamperry@fuchsia.infra.roller.google.com> | Wed Mar 26 10:37:20 2025 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Mar 26 10:38:58 2025 -0700 |
| tree | 1a5c25912bcfda51ca70407af5eacf7263c02cd2 | |
| parent | d7e6e2fdd7ddafe3a0efd2b7d52b50bd5be6dc24 [diff] |
[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
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance in one of the communication channels documented at get involved.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.