On Mon, Jun 26, 2023 at 2:27 PM Sergey Bugaev wrote:
> + /*
> +* Get rid of the entry without changing any wirings or the pmap,
> + * and without altering map->size.
> +*/
> + prev->vme_end = entry->vme_end;
> + vm_map_entry_unlink(map, entry);
>
struct vm_page is supposed to be a "small structure", but it takes up 96
bytes on x86_64 (to represent a 4k page). By utilizing bitfields and
strategically reordering members to avoid excessive padding, it can be
shrunk to 80 bytes.
- page_lock and unlock_request only need to store a bitmask of
This function attempts to coalesce a VM map entry with its preceeding
entry. It wraps vm_object_coalesce.
---
vm/vm_map.c | 77 +++--
vm/vm_map.h | 2 ++
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/vm/vm_map.c b/vm/vm_map.c
index
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 obje
When
- extending an existing entry,
- changing protection or inheritance of a range of entries,
we can get several entries that could be coalesced. Attempt to do that.
---
vm/vm_map.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/vm/vm_map.c b/v
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.
---
vm/vm_map.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/vm/vm_map.c b
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
Hello!
This is the kernel part of the VM work I've been doing lately. I'm no Mach VM
expert (much as I'm not an expert in anything really), but this looks
straightforward enough and seems to work well.
In the Hurd wiki, there's this open issue about "forward merging" VM map
entries [0]. To recap
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.
---
vm/vm_map.c| 12 ++--
vm/vm_ob
On Mon, Jun 26, 2023 at 2:11 AM Sergey Bugaev wrote:
> The user already has full access to our task, and the same kind of
> access to the file system image (if any) as our task does, we're not
> buying any additional security by disallowing them access.
This is not necessarily true considering mu
> I have a feeling that ACPI provides a list of possible IRQs per device
> and it's up to the host to figure out a set of unconflicting configurations
> and to set them using _SRS methods.
>
> Where can I find this info?
Check ACPI specification. Maybe the IRQ list are there.
El lunes 26 de jun
11 matches
Mail list logo
