Physical vs. virtual memory: How the two types compare
Physical memory wasn't enough for storage systems. Computer architects created virtual memory to ease the performance burden and work alongside the physical form.
A comparison of physical vs. virtual memory starts with two goals that are technically difficult to achieve together.
The ideal computer has an enormous memory but is still inexpensive. A large memory costs a lot, however, and an inexpensive memory is small enough to cause performance issues.
All the way back in the 1960s, computer architects realized the problems. How could they make a small memory do the job of a larger one? The answer was to fool the application programs into thinking that they had a much larger memory than was actually available.
Basic concept: Locality
A computer program has a lot of loops. A program goes over the same instructions many times and then moves elsewhere to execute another loop. A loop that calls on a subroutine repeatedly executes that same subroutine over and over.
This locality causes the processor to access the same set of memory addresses many times. It then moves to another set of addresses, which it accesses numerous times, and then repeats the cycle.
If admins can speed up the repeated access and only occasionally suffer from slow access, then overall performance should be pretty good. The processor executes a few instructions close to each other, so they are local, before moving on. Data often exhibits locality as well, but the bulk of a processor's memory accesses are for instructions, which is where the computer can get the greatest benefit.
Admins should store those repeated accesses in the fastest place, and in the 1960s, that was memory. They could leave slower accesses on the hard disk or even tape. When the processor moved from one address space to the next, the instructions and data could move from the slower media into memory for faster access at a relatively small overall penalty.
Fooling the processor
While computer architects tried software approaches to this problem, some decided to speed things up by creating a hardware approach that was invisible to the application program. When the application accessed an address, this hardware copied that address's data into memory, where it stayed until it was no longer needed.
Architects arranged the application so it thought the memory was as big as the system's storage. They called it virtual memory because it virtually appeared to be as large as the real memory available to the processor.
Now that they had virtual memory, they had to give a name to the system's real memory chips, so that became known as physical memory.
The physical memory is always far smaller than the virtual memory, yet it almost always appears to be in the right place at the right time.
How to fool a CPU
How do you fool a processor into thinking the memory is as big as storage? Make sure any address, no matter where it is, finds its way to physical memory.
Translate the address the application requests into an address that fits within the limited physical memory space, all on the processor chip in the memory management unit (MMU).
The MMU, under control of the OS, translates every address for either a fetch or a load into a different physical address, which is temporarily assigned to that virtual address. This isn't that hard to do in hardware: The address goes into a translation table memory that then spits out a different address. Software manages the mapping between these two addresses.
This translation is not for every virtual address. That requires an enormous translation table.
This spot's already taken
Any effort to map a large address space into a smaller one results in conflicts, and this is the case with virtual-to-physical mapping. When something needs to be moved from storage into virtual memory but every physical memory address is already in use, what do admins do?
A little bit more hardware provides a serviceable approximation of a "least recently used" algorithm to point out a virtual address that hasn't seen a lot of activity lately. The contents of this location are then evicted, and the requested data replaces it.
While most evictions, particularly for addresses that contain code, simply involve overwriting the memory location, admins must specially handle locations that contain modified data They need to write the modified location back to storage. The big trick here is to assign each physical memory address a dirty bit set when the address has been modified. Examine the bit upon eviction to see whether that address needs storage.
More physical vs. virtual memory differences
In the end, the physical memory is the tangible DIMMs in the system, and the virtual memory is what the OS presents to the applications. The physical memory is always far smaller than the virtual memory, yet it almost always appears to be in the right place at the right time.
A virtual memory system gives the illusion that the virtual memory is as fast as the physical memory and as large as the system's storage.
Jim Handy is semiconductor and SSD analyst at Objective Analysis in Los Gatos, Calif.
