MTS and the Thing King
It seems that my original page here contained some misinformation.
Fortunately, someone who both found this page and decided to check
caught the misinformation.
Special thanks to Jeff Ogden for the correction
Note: This was originally found at
It was periodically re-published in the University of Michigan
Computing Center (later called the Information Technology Department)
Newsletter, although I recall it being attributed to someone (probably Jeff
Berryman) at the University of British Columbia
The Paging Game
by Jeff Berryman, University of British Columbia, 1972
The Paging Game was written by Jeff Berryman
when he was working on project MAC, specifically one
of the virtual memory systems. The version best known to IBM and MVS sites from the mid-1970s
onwards is first, followed by the original:
THE PAGING GAME
*** RULES ***
- Each player gets several million *things*.
- Things are kept in *crates* that hold 4096 things each. Things in the same crate are called *crate-mates*.
- Crates are stored either in the *workshop* or in the *warehouse*. The workshop is almost always too small to hold all the crates.
- There is only one workshop, but there may be several warehouses. Everybody shares them.
- Each thing has its own *thing number*.
- What you do with a thing is to *zark* it. Everybody takes turns zarking.
- You can only zark your own things, not anybody else's.
- Things may only be zarked when they are in the workshop.
- Only the *Thing King* knows whether a thing is in the workshop or in a warehouse.
- The longer a thing goes without being zarked, the *grubbier* it is said to become.
The way to get things is to ask the Thing King. He only gives out things in crates.
This is to keep royal overhead down.
The way to zark a thing is to give its thing number. If you give the number of a thing
that happens to be in the workshop, it gets zarked right away. If it is in a warehouse,
the Thing King moves the crate containing your thing into the workshop. If there is no
room in the workshop, he first finds the grubbiest crate in the workshop, whether it be
yours or somebody else's, and packs it off with all its crate-mates to a warehouse. In
its place he puts the crate containing your thing. Your thing gets zarked and you never
even know that it wasn't in the workshop all along.
Each player's stock of things has the same numbers as everybody else's. The Thing King
always knows who owns what thing and whose turn it is, so you can't ever accidentally
zark somebody else's thing even if it has the same number as one of yours.
*** NOTES ***
Traditionally, the Thing King sits at a large, segmented table and is attended by
pages (the so-called "table pages") whose jobs it is to help the king
remember where all the things are and to whom they belong.
One consequence of Rule 13 is that everybody's thing numbers will be similar from
game to game, regardless of the number of players.
The Thing King has a few things of his own, some of which move back and forth
between workshop and warehouse just like anybody else's, but some of which are
just too heavy to move out of the workshop.
With the given set of rules, oft-zarked things tend to get kept mostly in the
workshop, while little-zarked things stay mostly in a warehouse.
Sometimes even the warehouses get full. The Thing King then has to start piling
things on the dump out back. This makes the game slow because it takes a long
time to get things off the dump when they are needed in the workshop. A forthcoming
change in the rules will allow the Thing King to select the grubbiest things in the
warehouses and send them to dump in his spare time, thus keeping the warehouses from
getting too full. This means that the most infrequently-zarked things will end up in
the dump so the Thing King won't have to get things from the dump so often. This
should speed up the game when there are lots of users and the warehouses are getting
Long Live the Thing King!
And here is something close to the original version, from the Project MAC manual.
THE PAGING GAME
Project MAC Computer Systems Research Division
*** RULES ***
- Each process gets several million *bytes*.
Bytes are kept in *pages* that hold 4096 bytes each. Bytes on the same page have
*locality of reference*.
Pages are stored either in *memory* or on the *disk*. The memory is almost always
too small to hold all the pages.
There is only one memory, but there may be several disks. Everybody shares them.
- Each byte has its own *virtual address*.
- What you do with a byte is to *reference* it. Everybody takes turns referencing.
- You can only reference your own bytes, not anybody else's.
- Bytes may only be referenced when they are in the memory.
- Only the *VM Manager* knows whether a byte is in the memory or on a disk.
- The longer a byte goes without being referenced, the *older* it is said to become.
The way to get bytes is to ask the VM Manager. He only gives out bytes in pages.
This is to keep overhead down.
The way to reference a byte is to give its virtual address. If you give the address
of a byte that happens to be in the memory, it gets referenced right away. If it is
on a disk, the VM Manager moves the page containing your byte into the memory. If
there is no room in the memory, he first finds the oldest page in the memory, whether
it be yours or somebody else's, and packs it off with the rest of the page to a disk.
In its place he puts the page containing your byte. Your byte gets referenced and you
never even know that it wasn't in the memory all along.
Each process's stock of bytes has the same virtual addresses as everybody else's.
The VM Manager always knows who owns what byte and whose turn it is, so you can't
ever accidentally reference somebody else's byte even if it has the same virtual
address as one of yours.
*** NOTES ***
Traditionally, the VM Manager uses a large, segmented table and "page tables"
whose jobs it is to help the king remember where all the bytes are and to whom they
One consequence of Rule 13 is that everybody's virtual address will be similar from game
to game, regardless of the number of processs.
The VM Manager has a few bytes of his own, some of which move back and forth between
memory and disk just like anybody else's, but some of which are just too heavyily used
to move out of the memory.
With the given set of rules, oft-referenced bytes tend to get kept mostly in the memory,
while little-referenced bytes stay mostly on a disk.
Sometimes even the disks get full. The VM Manager then has to start piling bytes on
the dump out back. This makes the computer slow because it takes a long time to get
bytes off the dump when they are needed in the memory. A forthcoming change in the
rules will allow the VM Manager to select the grubbiest bytes in the disks and send
them to dump in his spare time, thus keeping the disks from getting too full. This
means that the most infrequently-referenceed bytes will end up in the dump so the
VM Manager won't have to get bytes from the dump so often. This should speed up the
game when there are a lot of processs and the disks are getting full.
Long Live the VM Manager!
November 12, 2012
||Hello, a request about The Paging Game
||November 12, 2012 11:52:29 AM EST
I noticed that you had saved a copy of "The Paging Game" article at
I'm glad you did that. A few years ago I put a link to your page on the MTS Archive so it wouldn't get lost.
When I first read the article a couple of years ago, I noticed that it said that Jeff Berryman
worked at MIT's Project MAC when he wrote it. I hadn't known that Jeff worked on Project MAC and
wondered if it was true. But I didn't know a lot about Jeff's life before he came to UBC. And,
if you look at some of the other copies of "The Paging Game" that are on the Internet, many of
them attribute the article to Project MAC. So, I didn't worry too much about it.
A few days ago Mike Alexander sent me a note saying he'd noticed the attribution to MIT and
Project MAC, said it wasn't true, and lamenting that it was probably impossible to fix it.
That got me off my duff. I found an e-mail address for Jeff Berryman and asked him what the
real story was. Turns out that neither he nor the original article were ever associated with
Project MAC or MIT. I've created a couple of pages on the MTS Archive to capture this information:
And this got me wondering if you would be willing to update your page to reflect the fact that
Jeff worked at UBC and was never associated with Project MAC? Feel free to include any of the
links above, if that would be helpful. This would be a small step toward correcting the
historical record. And who knows, maybe it won't be impossible to correct a mistake that
is out on the Internet.
References (and more references)