🚀 go-pugleaf

In article <20534@netnews.upenn.edu> iyengar@grad2.cis.upenn.edu.UUCP (Anand Iyengar) writes:
>	What's the general feeling on future page sizes (I'm guessing that
>64K was picked here to make the page-tables smaller)?  Is it reasonable
>to assume that they are going to increase also (as bandwidth/latency
>increases), or will we lose more by making pages larger?  

A past coworker of mine was proposing that bigger pages would be a good idea
several years ago, and I tend to agree.  The only thing you loose with
bigger pages is memory utilization because of breakage (probably > page size/2
since segment size is not uniformly distributed), and you gain on several
fronts:  fewer page faults (loading 64k in one page fault takes much less
than faulting 16 times for 4k pages), fewer TLB misses, and generally less
paging overhead since all the data structures are smaller (page tables, etc.).
Since memory is cheap relative to anything you can do to improve CPU
throughput, bigger pages should be a win.

Of course a 4M machine, you can only have 64 64k pages, which isn't a very
big working set.  But then, 4M is rapidly becoming a small machine, so this
probably isn't a big problem.  If you MMU design can handle short pages (i.e.
ones smaller than the page size, with the tail unallocated), then you get the
best of both worlds, except for a little more complexity since pages aren't
all one size anymore.

Gerry Gleason