So you can have virtual address space “usage”, commit “usage”, and physical page “usage” (which can be shared between processes).
And that’s just anonymous memory, file backed gets even more complicated. Are pages that are in file cache but no longer mapped into a process counted as “usage”?
Anyways, for an introduction to a topic I would expect more links to background information, and you can go very deep trying to answer the question of how much memory an application is using. And the first step is to carefully define “memory” and “using”.
Edit: Actually it looks like the behavior might have changed. hmmm. I guess read the man pages tied to the kernel you're using
Edit 2: Nope, I misread the most recent manpage. I should not read manpages when I'm tired. It does zero fill specifically for anonymous mappings
For example, using a std vec is a very common pattern for a simple dynamic array, but the whole array content is copied every time it resizes, a cost that is more or less amortized because of the doubling in size every time.
Yet, a very large virtual memory block will have the added benefit of address stability, simplicity of implementation and zero copy, of course there is no free lunch as the page fault triggering the page allocation when needed will interrupt the process.
I should make some benchmark to compare the different approaches at some point…
To me what you are proposing seems like a clever way of allocating that has a pretty restricted use.
...of what size? is the problem
And there are a myriad of command incantations to massage existing data in one-liners 
 - https://github.com/pixelb/ps_mem/
 - https://www.commandlinefu.com/commands/matching/memory/bWVtb...
You can just allocate in units of 4, or however many pages at once; and trust the OS's ability to speculate accesses. The main advantage of larger pages is smaller page tables and higher TLB hit rates.
Not always right? Atleast in x86 - switching to huge pages also decreases TLB size afaik.
$ x86info -c
Instruction TLB: 4K pages, 4-way associative, 128 entries.
Instruction TLB: 4MB pages, fully associative, 2 entries
Data TLB: 4K pages, 4-way associative, 128 entries.
Data TLB: 4MB pages, 4-way associative, 8 entries
I see no reason why key decisions in the micro-optimizations space could not lead to emergent page minimums.