The whole article is based around the idea the machine is dedicated to one large process, and that the working set fits in RAM. If that is the case, great turn on boot time 1GB page preallocation and have don't look back.
If either of those two assumptions are false, then the TLB miss times are swamped by the page in time. Paging a 1GB page in is _NOT_ a fast operation, especially when only a tiny percentage of the data is going to be touched, or its promptly going to be paged out again. If he has a machine with 32GB of ram he should retest with a 64GB working set.
The whole article is about optimizing a 1) large memory 2) single process that 3) dominates the CPU time on one machine where 4) the entire working set fits in ram. If any of those FOUR conditions are not met, then the conclusions do not apply.
That being said, we have an in-memory custom content db where this tweak might really make a difference..
You seem to be one of those people who thinks whether you have 1G, 2G, 4G, 8G, 16G, 32G, 64G, or 128G... of RAM, you'll still page out to disk eventually.
How much exactly do you consider to be the minimum 'enough' RAM where you won't need to page out to disk? 128 exabytes?
Paging to/from disk is currently a fundamental portion of all the major OS's, and significantly increases ram efficiency (even for executable pages). I still see a fair number of server applications oversubscribing RAM. Particularly in DB, or VM'ed environments.
I'm not saying 4K pages are good and 1G ones are bad, but there are a fair number of applications that probably benefit from something in between. 1GB is probably on the extreme side of things.
That doesn't mean you need 50TB of RAM, because 99% of the records could be inactive. Instead you let the hardware page things in, and the portions of the database that are regularly used will stay in RAM, while the rest remains on SSD. The arches with more page selection choices can actually be a big selling point for non x86 servers in certain cases.
In the end, retained data is still growing, and a fair number of applications don't fit into mapreduce or other partitioning schemes. So, I would say paging is going to remain useful for some portion of the servers in existence for at least a few more years.
BTW: I recently worked on an application which would pretty much eat as much RAM (enormous hash table) as it was given and still ask for more. In the end shipping a fairly normal machine (32G-64G) with a 4TB PCIe based SSD provided sufficient performance that we didn't need to spend 100x on a machine that could take 4TB of RAM. So there are economic arguments as well.
Can you share any more about your use case here? Intrigued, as a colleague and I have recently been working on highly space-efficient hash maps for a bioinformatics application that it strikes me could be relevant (similar problem -- huge reference set that needs to be accessible with very low access times).
Paging is not fast, period. I think it's a reasonable assumption that the machine is not paging. That said, if you rely on paging, then your comment holds.
If either of those two assumptions are false, then the TLB miss times are swamped by the page in time. Paging a 1GB page in is _NOT_ a fast operation, especially when only a tiny percentage of the data is going to be touched, or its promptly going to be paged out again. If he has a machine with 32GB of ram he should retest with a 64GB working set.