Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site decwrl.UUCP
Path: utzoo!linus!decvax!decwrl!dec-rhea!dec-oracle!waters
From: waters@oracle.DEC (Greg Waters, 225-4986, HLO2-1/J12)
Newsgroups: net.arch
Subject: Page size and the meaning of life
Message-ID: <926@decwrl.UUCP>
Date: Sun, 20-Oct-85 13:43:39 EDT
Article-I.D.: decwrl.926
Posted: Sun Oct 20 13:43:39 1985
Date-Received: Tue, 22-Oct-85 06:32:18 EDT
Sender: daemon@decwrl.UUCP
Organization: Digital Equipment Corporation
Lines: 59

[Forgive me for commenting without having read the literature....  Everyone
else does!]

Rich Hammond, Bellcore, writes:
> You don't have to keep the page tables in dedicated memory (I assume you
> mean fast static RAM), the DEC VAX and the NS32000 family both have caches
> of frequently used page table entries and keep the rest in main memory.
> The thing I would hope that Motorola does better is allow a larger size
> page (VAX and NS320000 use 512 bytes/page).  As dynamic RAM gets less
> expensive per bit it makes sense to accept greater internal fragmentation
> in pages in return for smaller page tables.

I agree, memory is getting cheap.  So why complain about small pages?  The
VAX has small pages, and VMS (perhaps some enhanced UNIXes also) has put
them to good use!  Such creative use of page tables solves about half of
the problems discussed in recent net.arch postings.  To wit:

1.  If you'll accept fragmentation in pages because memory is cheap, then,
    say, a doubling in page table size should also not worry you.  After
    all, even the page tables are virtual.  And you don't need a huge
    translation lookaside buffer when the pages are smaller, because only
    large-array crunching programs can touch lots of pages at once.  Most
    programs would touch only slightly more 512B pages than 2KB pages within
    a very short period of time.

2.  I agree, page faulting is inefficient with 512 byte pages.  That's why
    a VAX OS shouldn't fault 512 byte pages.  The size of a page fault can
    be tuned in software to any multiple of 512 that you like.

3.  The page size determines protection and mapping granularity.  Am I wrong
    in thinking that the smaller the pages, the closer you are to having
    certain benefits of an object-based memory system?  In some applications,
    you may want lots of different memory regions with different protection.
    And the fine-grained mapping lets you share reasonably small data regions
    between processes.  I hear that UNIX doesn't do much with that capability,
    but the multiprocess data sharing support is there under VMS.  No sweat
    sharing read-only code, and sharing data with different protection for
    each process is easy too.

4.  I saw a lot of complaints in net.arch lately about powerful debugging
    features.  People wanted to trap reads of uninitialized data, trace writes
    to a variable to figure out who's trashing it, etc.  In real time systems,
    you do this with a logic analyzer whose trigger output interrupts the CPU.
    But for non-real-time program development, you do it with a debugger that
    knows how to use the page table.  When the pages are small (128 longwords
    per page in VAX), the performance is good enough for program development.
    The debugger can trap accesses to an entire page when the user has enabled
    uninitialized variable checking.  The debugger then checks what variable
    is being touched, and lets the program continue if it's not a watched
    variable or if it has already been written to.  For watchpoints, the
    debugger traps only write accesses to the page.


Almost anything that you can do with a page table becomes a little more useful
when the pages are small.  So, can someone tell me why there's an overwhelming
demand for large pages?

				Greg Waters
				...decvax!decwrl!dec-rhea!dec-oracle!waters