Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!zds-ux!gerry From: gerry@zds-ux.UUCP (Gerry Gleason) Newsgroups: comp.arch Subject: Re: 64-bit addresses Message-ID: <204@zds-ux.UUCP> Date: 2 Mar 90 16:42:03 GMT References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil> <3606@uceng.UC.EDU> <757@dgis.dtic.dla.mil> <4852@scolex.sco.COM> <29718@brunix.UUCP> <20534@netnews.upenn.edu> Reply-To: gerry@zds-ux.UUCP (Gerry Gleason) Organization: Zenith Data Systems Lines: 24 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