"That only happens if the whole..." <- Let me clarify things a bit, since I was half asleep and on my phone when I wrote this. Suppose that we have reserved a 64KB region (16 pages). Then, I want to commit 2 pages starting from an 8KB offset. Then, I want to commit again, this time involving **4** pages starting from a **4**KB offset. The second commit involves a range that contains _other_ pages that have already been committed. On Windows, this work perfectly: The first `VirtualAlloc` call with `MEM_COMMIT` commits my first two pages, while the second `VirtualAlloc` call with `MEM_COMMIT` commits the other two pages (one at 4KB and the other at 16KB), leaving the two pages in the middle unchanged. This is hard to emulate on Haiku. As we cannot clear the overcommit status by using `mprotect`, we must remap the memory that is being committed. The first commit (involving the middle two pages) should work fine when using a `mmap` with `MAP_FIXED`, but the second commit would not as `mmap` would destroy the old pages and replace them with new, blank ones. It is possible to emulate this on Haiku by using `area_for`/`get_next_area_info` to avoid existing mappings, but as with all approaches using a loop of `get_next_area_info`, it is not really clean and vulnerable to race conditions.