Nov 11, 2026, 8:39 PMFor clarity, it is more important my function run correctly on BSD derived systems than Linux derived systems
- Nov 11, 2026, 8:39 PM
Replies
- Nov 11, 2026, 9:15 PM
2nd odd question.
The person calling on me to write "partial deallocate" also wants me to return the "allocate page size" and "commit page size". They provided a Win32 implementation, I must write UNIX/Linux. here is what I believe is happening.
- Windows vmem has two operations, "allocate" and "commit". These operations have different requirements for the range size.
- On UNIX/Linux, these operations correspond to "mmap" and "mprotect". They BOTH use sysconf(_SC_PAGE_SIZE) for size multiple.
- Nov 11, 2026, 9:15 PM
(The above post glosses over MAP_ANONYMOUS for lack of space, but it is not important to my question.)
John Ripleyjripley@mastodon.socialNov 11, 2026, 9:25 PM@mcc I think "commit" is closer to Linux "mlock" than "mprotect". What it's doing is making a page deterministically accessible. In Linux, a page may fault non-deterministically on first access, even if you allocated backing store (anonymous or otherwise). You can either trigger allocation by striding through the range, and taking access faults (annoying to handle), or by locking the range (enforces pages present).
- Nov 11, 2026, 9:31 PM
@jripley That's very interesting. However, would you agree this mlock operation occurs on whole pages (eg the same page size used for mprotect and mmap(MAP_ANONYMOUS)?
- John Ripleyjripley@mastodon.socialNov 11, 2026, 9:36 PM
@mcc If you asked this before the existence of non-4KB virtual memory architectures, I'd say yes. I'm not sure how Linux or the BSDs ended up reconciling architectures where there may be a different granularity of memory protection vs address mapping. I'm not sure if POSIX covers this, or would have thought to cover this specific case, either. (I do know that other OS allow for different granules, and it is *annoying*)
- John Ripleyjripley@mastodon.socialNov 11, 2026, 9:31 PM
@mcc To be clear, there's only a distinction here when you are in *OOM* condition. In Linux, first access is when you discover you are OOM, and your process takes a page fault, or is simply killed. You can make this deterministic by calling mlock() but then (depending on your global OOM config) that may only serve to make your process get killed at that function call.
- Nov 11, 2026, 9:34 PM
@jripley This is very educational. However, for purposes of my task today, imagine we care very much about BSD derived systems (MacOS 10+, and a second platform I am forbidden from speaking the name of aloud) and very little about Linux. Does your advice change?
- John Ripleyjripley@mastodon.socialNov 11, 2026, 9:46 PM
@mcc (merging threads) Apple arm64 platforms are the cases I had in mind where you might encounter a finer granule of memory protection vs address mapping. It varies by platform (Mac vs iOS) and whether it's under emulation. I *think* this all got reconciled by simply going with the (less efficient for both hardware and software) 4KB page size, because there's too much legacy software which would otherwise break. But I'm out of usefulness here—I didn't touch any of this after shipping A7 :)