diff options
| author | Sergey Bugaev <bugaevc@gmail.com> | 2023-06-26 14:26:54 +0300 |
|---|---|---|
| committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2023-07-03 02:20:30 +0200 |
| commit | cab23fb54d10843158e874d87dd3725ddbb2b4db (patch) | |
| tree | 7a3c118c58dba82b088baf52beab4f093e9f1e12 /vm/vm_object.h | |
| parent | d57189313d359bfa4033d24b3c4248b539826763 (diff) | |
| download | gnumach-cab23fb54d10843158e874d87dd3725ddbb2b4db.tar.gz gnumach-cab23fb54d10843158e874d87dd3725ddbb2b4db.tar.bz2 gnumach-cab23fb54d10843158e874d87dd3725ddbb2b4db.zip | |
vm: Eagerly release deallocated pages
If a deallocated VM map entry refers to an object that only has a single
reference and doesn't have a pager port, we can eagerly release any
physical pages that were contained in the deallocated range.
This is not a 100% solution: it is still possible to "leak" physical
pages that can never appear in virtual memory again by creating several
references to a memory object (perhaps by forking a VM map with
VM_INHERIT_SHARE) and deallocating the pages from all the maps referring
to the object. That being said, it should help to release the pages in
the common case sooner.
Message-Id: <20230626112656.435622-6-bugaevc@gmail.com>
Diffstat (limited to 'vm/vm_object.h')
0 files changed, 0 insertions, 0 deletions