[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[SCM] GNU Mach branch, master, updated. v1.8-661-gcab23fb5
From: |
Samuel Thibault |
Subject: |
[SCM] GNU Mach branch, master, updated. v1.8-661-gcab23fb5 |
Date: |
Sun, 2 Jul 2023 20:23:44 -0400 (EDT) |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Mach".
The branch, master has been updated
via cab23fb54d10843158e874d87dd3725ddbb2b4db (commit)
via d57189313d359bfa4033d24b3c4248b539826763 (commit)
via ee65849bec5da261be90f565bee096abb4117bdd (commit)
via dc0c9160173d2a5b40e9d6e29c1800102b17b1ec (commit)
from 505ecd7b30fca1dc296205ff3c0dc3aff9d76e12 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit cab23fb54d10843158e874d87dd3725ddbb2b4db
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Mon Jun 26 14:26:54 2023 +0300
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>
commit d57189313d359bfa4033d24b3c4248b539826763
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Mon Jun 26 14:26:53 2023 +0300
vm: Allow coalescing entries forward
When entering an object into a map, try to extend the next entry
backward, in addition to the previously existing attempt to extend the
previous entry forward.
Message-Id: <20230626112656.435622-5-bugaevc@gmail.com>
commit ee65849bec5da261be90f565bee096abb4117bdd
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Mon Jun 26 14:26:52 2023 +0300
vm: Allow coalescing null object with an internal object
Previously, vm_object_coalesce would only succeed with next_object being
VM_OBJECT_NULL (and with the previous patch, with the two object
references pointing to the same object). This patch additionally allows
the inverse: prev_object being VM_OBJECT_NULL and next_object being some
internal VM object that we have not created a pager port for, provided
the offset of the existing mapping in the object allows for placing the
new mapping before it.
This is not used anywhere at the moment (the only caller, vm_map_enter,
ensures that next_object is either VM_OBJECT_NULL or an object that has
a pager port), but it will get used with the next patch.
Message-Id: <20230626112656.435622-4-bugaevc@gmail.com>
commit dc0c9160173d2a5b40e9d6e29c1800102b17b1ec
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Mon Jun 26 14:26:51 2023 +0300
vm: Allow coalescing a VM object with itself
If a mapping of an object is made right next to another mapping of the
same object have the same properties (protection, inheritance, etc.),
Mach will now expand the previous VM map entry to cover the new address
range instead of creating a new entry.
Message-Id: <20230626112656.435622-3-bugaevc@gmail.com>
-----------------------------------------------------------------------
Summary of changes:
vm/vm_map.c | 77 +++++++++++++++++++++++++++++++++++++----------
vm/vm_object.c | 95 +++++++++++++++++++++++++++++++++++++++-------------------
2 files changed, 127 insertions(+), 45 deletions(-)
hooks/post-receive
--
GNU Mach
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [SCM] GNU Mach branch, master, updated. v1.8-661-gcab23fb5,
Samuel Thibault <=