Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@odin.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: 64-bit addresses Message-ID: Date: 4 Mar 90 22:14:12 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> <204@ Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 82 In-reply-to: gerry@zds-ux.UUCP's message of 2 Mar 90 16:42:03 GMT In article <204@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes: 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? We will lose a lot. For *general purpose* machines the number of useful bytes that you can pack on a page is not very large. 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), The 8KB page size of most SUNs tends to waste, I suspect, about 40% of available memory. On general purpose timesharing/workstation systems most files are much smaller than 8KB. Greater fragmentation implies poor locality, and the last thing we need now is even less locality. 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), The difference is less marked than you might expect, and might be vanishingly small, if the IO subsystem is supportive (both HW & SW), e.g. hardware scatter/gather and software fetch-ahead and discard-behind (as described in Knuth's Vol. 1)... fewer TLB misses, and generally less paging overhead since all the data structures are smaller (page tables, etc.). This really matters only if you use direct map MMUs... Since memory is cheap relative to anything you can do to improve CPU throughput, bigger pages should be a win. A resource being cheap is no reason to squander it. Unless you are a manufacturer and you sell it to your customers with a huge markup... 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. Here you should reconsider your opinions. 64 64K pages is not a problem, if locality of reference is such that the working set of an application does not increase because of the larger page granularity. This depends on how much related data you can manage to cluster together on a page. If the working set of an application rises in direct proportion to the page size, raising the page size is not going to give you *anything*, except kudos from MITI. If you can only manage to cluster say 2-4KB of data frequently accessed together on a page, using 64KB pages will just waste 60KB of real memory per page. As the Unix designers observed as to whether double the Unix filesystem blocksize from 512B to 1KB, this will work only if the amount of useful data per page will also (almost) double, and this is not by any means guaranteed (unless you are doing strictly sequential access). In other words, let me repeat that large page sizes are a poor, static way of doing clustering, and one that is too rigid and inefficient. Clustering should be dynamic. If you do static clustering only applications that do sequential access will benefit. Even worse, applications will be written with the expectation that only sequential access is desirable, which is a sorry state of affairs. 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. Why don't we go all towards Burroughs like variable length descriptor machines then? It is actually a good idea, as long as you have ways (dynamic clustering, object secondary store, whatever) to compensate for the well known fact that the average segment size on a descriptor machine is only a dozen words long. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk