🚀 go-pugleaf

In article <6998@celit.fps.com>, ps@fps.com (Patricia Shanahan) writes:
> In article <29718@brunix.UUCP> phg@cs.brown.edu (Peter H. Golde) writes:
> >One might note that implementing a 64-bit address space
> >with 64 KB pages and 8 bytes/page in the page table requires
> >2 billion megabytes of page-table space.  Hmmmmm.....
> >
> >--Peter Golde
> 
> 
> If the real memory is small compared to the address space, don't use page
> tables. If you must use page tables, design them as sparse arrays.
> If the real memory is large, you would probably want a bigger page
> size anyway.
> 
> Those systems I am familiar with that seemed to have a good fit between
> page size and memory size had the page size approximately the square root
> of the memory size of a largish system. Anyone know of any counter-examples?
> --

The virtual-memory supers in the CDC Star-100/Cyber 20x/ETA-10 line solved
this problem by having multiple page sizes.

The early machines (Stars and 203's) had anywhere from 4 to 8MB of 
physical memory.  VM translation by pages had two flavors, "small"
and "large".  The size of a small page was 4KB; a large, 512KB.  Thus,
the small page was anywhere from .5*sqrt(sizeof(PM)) to .25 (ditto).
The large page was there due to the use of associative registers to
hold the last 16 page table entries.  In an 8MB machine, 16 AR's held
translation for the entire physical memory, when large pages were used.
Any process was allowed to have a any mix of small and large pages.

The later machines were similar, but the OS'es were extended to support
multiple sizes of small pages - 4, 16, and 64KB - selectable at boot
time.  Large pages were still 512KB.  The exception was the ETA-10,
which had two sizes of large pages - the 512KB and the "giant" page,
which was 4MB.  The ETA-10 still had 16 AR's for VM translation;  thus,
16 "giant" pages corresponded to 64MB of physical memory, which was the
base amount for all ETA-10 processors.  NB, the "giant" page was never
given OS support.  

Moral of the story?  As physical memory size grows, virtual page size
*ought to* grow as well.  For simplicity's sake, if nothing else.

Rob
> 	Patricia Shanahan
> 	ps@fps.com
>         uucp : {decvax!ucbvax || ihnp4 || philabs}!ucsd!celerity!ps
> 	phone: (619) 271-9940


-- 
Rob Peglar	Control Systems, Inc.	2675 Patton Rd., St. Paul MN 55113
...uunet!csinc!rpeglar		612-631-7800

The posting above does not necessarily represent the policies of my employer.