Login
You're viewing the appalorchard.com public feed.
  • mccmcc@mastodon.social
    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.

    💬 2🔄 0⭐ 0

Replies

  • mccmcc@mastodon.social
    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.)

    💬 0🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 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).

    💬 2🔄 0⭐ 0
  • mccmcc@mastodon.social
    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)?

    💬 1🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 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*)

    💬 0🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 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.

    💬 0🔄 0⭐ 0
  • mccmcc@mastodon.social
    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?

    💬 1🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 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 :)

    💬 1🔄 0⭐ 0
  • mccmcc@mastodon.social
    Nov 11, 2026, 10:05 PM

    @jripley Okay, thank you.

    Repeating what you said back to you:

    On normal UNIX/Linux, mmap, mprotect and mlock all use sysconf(_SC_PAGE_SIZE) multiples. But on recent MacOS, mprotect and mlock may use a different size; using sysconf(_SC_PAGE_SIZE) is always safe, but a smaller (divisor) size may potentially be allowed.

    If this is correct, my question is:

    How do I find out the allowed mprotect/mlock size multiple on mac?

    💬 0🔄 0⭐ 0
  • mccmcc@mastodon.social
    Nov 11, 2026, 10:05 PM

    @jripley The MacOS 26 (on ARM) mprotect manpage reads "Not all implementations will guarantee protection on a page basis but Mac OS X's current implementation does" but does not mention sub-page arguments being legal.

    💬 1🔄 0⭐ 0
  • John Ripleyjripley@mastodon.social
    Nov 11, 2026, 10:44 PM

    @mcc (Deleted previous post) I think I'm describing behavior which never made it into releases. It looks like mmap/mlock/mprotect these days on Mac/iOS all function in the intuitive way on a 16KB granule (arm64), and the existence of smaller granules is something you'd only encounter in x86 emulation. So, looks like sanity prevailed.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0