hckrnws

Nice reference, thanks.

HDD: sudo dd if=/dev/urandom of=/dev/sdX bs=1M status=progress

> The operating system often has a tool for allocating contiguous virtual memory space called pages.

"often". sheesh. *rolls eyes*

It does not apply for Windows.

You cannot reserve or commit 4k-pages in Windows. For historical reasons, the minimum amount of memory you can reserve/commit is 64k.

This also applies to mapping 4k-pages around, meaning you can't.

64k is the rather wastefull lower limit.

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.

Ha! You're right! It applies to reservation and mapping, not to committing!

Thank you, it's been a while!

How does WSL1 do it then?

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