6

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?

2
  • 3
    A VAX in the 70ies with a page size of 2 MBytes - How many pages would it have had? What was a typical program size/memory footprint of a program back then? Some things have actually changed since then.... That question hasn't much to do with "engineer's mindsets"
    – tofro
    Jun 4 '19 at 19:44
  • 1
    You're wrong with your tendency to 2 MB pages. No sane computer would implement something like that. Providing the option of big pages is ok, Removing small pages would be stupid. Going to 8K or 16K pages can be envisioned and make sense (Sparc had 8k pages, Apple uses now 16k pages in iOS) but they are still essential for performance. You may read some of Linus Torvalds rants on that subject at realworldtech. he explains there why small pages (4K to 16K) are essential and will never go away. Sep 30 at 9:44
11

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.

7
  • 3
    Concur with the "match (PDP11) disk block size"; I can't find a reference, but I recall understanding that as the rationale at the time. Jun 4 '19 at 21:52
  • 1
    There was no S1 segment in the virtual address space; not implemented. "Reserved", as they say. 3GB ought to be enough for anyone, anyway :-) Jun 4 '19 at 21:55
  • 1
    I can't find anything in the VAX architecture that looks like an extension to PDP-11. A sound architecture on its own right. PDP-11 compatibility was abandoned quite soon. Yes there is some heritage but VAX and PDP-11 are still completely independent architectures.
    – lvd
    Jun 5 '19 at 15:53
  • 2
    The VAX designers thought they were building an -11 with eXtended Virtual Addressing. The 1979 System Reference Manual says "The VAX-11 is a family of upward-compatible computer systems. It is a natural outgrowth of and is heavily compatible with the PDP-11 family". I, as a PDP-11 and then VAX programmer, regard the latter as based on the former; the instruction set and operand formats are not surprising. Certainly the VAX is even less like any other DEC computer of the time. But all this seems like a subject for another question. Jun 5 '19 at 22:40
  • 2
    @KenGober The original name "VAX-11" literally means virtual address extension [of the PDP]-11. The earliest VAXes like the VAX-11/780 had a bit in their status register (or equivalent), that, if set, made them binary compatible with the PDP-11 instruction set.
    – JeremyP
    Sep 30 at 7:56
8

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.

1
  • PDP-11 itself had 8k pages.
    – lvd
    Oct 1 at 11:54
3

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.

2
  • Doesn't a range of 1000:1 seem ambitious? 3 orders of magnitude! IBM System/360 - from '65 to '71 - achieved it for "scientific performance" but not in any other area - ranging between 250-350 times improvement. Later versions, of course, starting with the 370 to the present day have gone way way further!! But I wonder what their targeted range of implementation was (back in 1963)? (Plus, Digital wasn't IBM, had brilliant guys yes, but not as many nor as much resources.)
    – davidbak
    Oct 5 at 0:25
  • I think 1000:1 is to be understood as 'system size' and not necessarily raw CPU. So, for example, the low end was envisioned to be a 'terminal' where the ability to have small memory would be important. And of course it was the goal over the lifetime of the architecture; the "all our eggs in one basket" plan. What in fact was the spread between a MicroVAX I and a VAX 10000? Oct 5 at 1:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.