Hacker News Reader

Comment by etep | Hacker News Reader

I think it is much simpler. 4 KB pages are small today, and 1 GB is still very large for most processes. 2 MB sounds about right (gut check, how much memory does the average process allocate, and for those small processes, is 2 MB that much overhead really?). Unless the number of TLB entries drops as page size increases, then larger pages make sense. It's simple: 1 GB risks wasting memory when the process doesn't need that much. 2 MB is good in 2014.

View on HN

I think it's a bummer that there aren't some option in between. I could see 64 meg pages being really nice.

Ultimately it would be handy to be able to tune page size for the loads that you see. I could see page sizes jumping by 4x or 16x (2 bits or 4 bits) each time being reasonable.

The real issue the author is talking about isn't "how much memory does a process allocate" but rather "how many total pages does the OS have to keep track of and what percentage of those fit in the TLB at any one time?"

If the real issue is simply to minimize the number of pages to track (and thereby maximize TLB hits) then its very simple: go to 1 GB (or higher!) pages.

This hints that there is a tradeoff happening here. At the highest level, the tradeoff is between having efficient use of memory and TLB hits. Big pages give TLB hits, small pages make efficient use of memory.

Since the TLB is in hardware, it is more difficult to have the fine-grain tuning you desire.

PowerPC on Fedora now defaults to 64k pages, I happened to notice the other day, which surprised me. But x86 doesnt have convenient size pages that would work for default, as 2M is a bit big probably.

Reply on news.ycombinator.com