Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
MMU page size in VAXen is just 512 bytes. Such a small size causes increased number of MMU page walks and leads to TLB thrashing more often. Current tendency is to have MMU pages as big as 2 Mbytes.
However, back 70ies, when VAX architecture was postulated, the computing world was totally different and engineers kept different mindsets.
So what were the most probable reasons behind selecting such a small page size?
The first and most important point to keep in mind is that the VAX wasn't initially designed as a new architecture, but an extension to the basic PDP-11 structure to break its 64 KiB boundaries. Early implementations even offered a hardware-based PDP-11 mode.
MMU page size in VAXen is just 512 bytes
Which is also the block size of most DEC disk drives (sans RF/RS11). Using the same block size to segment memory does have its practical benefits, doesn't it?
Not to mention that 512 bytes were still a lot in 1977. A time when even real, /370 class mainframes were still delivered with little memories like 256 KiB and used for large scale applications. The /370, by the way, also had 'just' a 4 KiB page size (double the disk block size) - systems that even today rule the systems at the core of our economy.
Such a small size causes increased number of MMU page walks
Except that the VAX page table system was rather simple and single level (per region *1). So not much walking, just straight indexing.
In fact, one of the funny aspects of the VAX's page table system is that the page tables (*2) themselves are/can be stored in pageable memory (*3) :)
and leads to TLB thrashing more often.
With 128 entries in the first KA780, the TLB covers quite a lot of entries considering that it's a cache. Later models like the later 11/750 or 11/785 even had 512 entries.
Current tendency is to have MMU pages as big as 2 Mbytes.
Yeah - as well as having program sizes in the multi-megabyte and memories in multi-gigabyte sizes.
The original VAX in 1977 (11/780 or KA780) had a base memory of 128 KiB (256 pages) and a maximum possible amount of 2 MiB (*4).
*1 - The addressing scheme diverted the 4 Gi address range into four 1 Gi blocks, each handled by a pair of registers holding the address of the corresponding page table and its length. The lower two Gi were for program space while the upper handled system space. In each, the lower Gi was allocated from the bottom, the upper from the top. Loading a page entry into the TLB was a single address calculation of the entry address by adding the page number to the table address register (P0 or P1 for user context) and loading the entry into the TLB. Simple and fast, isn't it?
*2 - Each process got two plus the system table for all. So only 4 registers had to be changed for a process swap, everything thereafter was accessed when used on an entry by entry scheme and cached in the TLB.
*3 - Quite a useful combination as the tables themselves could become quite large - due to the small page size that is. Then again, with 32 bits per entry a 512 byte page could hold 128 entries, good for 64 KiB.
*4 - Later extended to 8 MiB.
512 bytes was the size of a block on disk. making page size the same as a disk block made calculating swapping very simple and fast.
It was a throwback to the PDP-11. The original VAX 11/780, was meant to be an upgrade from the PDP-11 and had compatibility modes built in. (I remember when most of the utilities for VMS were simply the RSX-11 programs running in compatibility mode.)
The block size and the cluster size defined the minimum amount of disk space used and transferred in an I/O.
A 1979 strategy memo from Gordon Bell recaps the rationale for the page size choice they made in 1975.
From page 14 in the PDF (use the PDF page numbering, it appears to contain multiple documents with their own page numbering):
The VAX architecture was designed to permit the building of a range of machines with sizes that are important to us. Our targeted range of implementation was 1000: 1 and this is attainable with an LSI implementation for terminal applications in January 1982. This is why a small page size and simple paging system was chosen, versus a larger page size and more complex scheme that would have been particularly oriented at large systems.
So, it sounds like the architectural committee's main concern was the ability to build small systems at a suitable price point in the early 1980s.
