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).
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.
If you have a 50TB database you cannot put it in ram on anything common. The largest machine I've seen for sale takes 16TB of ram http://www-03.ibm.com/systems/power/hardware/795/specs.html.
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.