🚀 go-pugleaf

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