And the historical reason why the allocation-granularity is 64 KB instead of 4 KB (or the page-size) is that it made DLL relocation very slightly faster on Alpha AXP processors. No, really! https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42...

Can you clarify?

As far as I'm aware, dwAllocationGranularity returned via GetSystemInfo determines the MEM_RESERVE alignment and size. Yes, in practice this is always 64KiB but may not always be true in the future.

Additionally, dwPageSize returned via GetSystemInfo determines the alignment and size for MEM_COMMIT which in practice is 4KiB or 16KiB.

Put differently, while an application might be stuck with allocation-granularity reservations, the actual commit is in units of page size, right?

https://learn.microsoft.com/en-us/windows/win32/memory/reser...

Page protections are also based on page size afaik, for example: https://www.softwareverify.com/blog/leaking-memory-with-virt...

Or the way I read it, you might be stuck with a dwAllocationGranularity reservation, but the actual commit increment is in units of dwPageSize.

How does WSL1 do it then?

Anyway, the section you are quoting makes no claim as the the permitted granularity.