commit-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]