RAM disks and page files.

I've run across some bad information on the Internet more than a few times lately, and it prompted me to try to counter this misinformation about optimizing workstation computers with gobs of RAM.

The tl;dr version is: leave your RAM alone, let the operating system manage it. Teams of people smarter than you and I have figured this problem out.

The Problem:

The advice is basically that emulating a hard-drive/ssd with system RAM will speed up your system, and that moving your paging file to the RAM Disk can improve system performance. That is just wrong. Why does this idea never seem to die the death it deserves? I think there is a lot of misunderstanding of what a page file is. There seems to be this idea that the reason a PC is running slow is because it's spending too much time writing to the paging file. 

How paging files work.

All modern desktop operating systems support the idea of a paging file. In short, a page file is the operating system's way allowing programs to ask for more RAM than what actually exists. In the old days, when RAM was used up, the operating system simply returned an error when a program asked for more memory. The purpose of a page file is not to speed up a computer, it is to allow your drivers and applications to have access to more memory than is actually available on the system. Indirectly, a paging scheme can make available more RAM for other uses, which does lead to high performance. 

Mental experiment: a femto computer:

For the sake of explanation, let's imagine a tiny computer, with only 8 bytes of RAM. Despite it's infinitesimal size, it's got a magical operating system that takes no RAM for itself, runs multiple programs at once, and can manage a page file.

Precursor: Virtual Address space. 

To make paging possible, the femtocomputer needs to support virtual addressing. Virtual addressing lets each program see it's own private view of memory, independent of the real physical address of the memory. the hardware of the CPU does "address translation" to map to virtual address to a real address. Imagine we have two programs running on our femtocomputer:

Nothing exotic going on here

Both applications in their own processes see their RAM starting at address "0". They don't know what physical address the memory is mapped to, and they don't need to know 99.9999% of the time. The two green bytes are still free for anyone to use, they don't even have to be next to each other or in order, though if it helps performance, the operating system will do it's best to arrange that way.

Now let's see what happens when process two asks for 2 more bytes:

Oh no! We're out of memory! Time to
upgrade to the femto computer II?

There's not a tremendous gain in using virtual addressing here, is there? The system can be a little more flexible in how it used physical ram, and each process is automatically protected from another process accessing its memory, but each program can easily cause the system to run out of memory. The real benefit is that a virtual memory makes page file systems possible, 

Paging files to the rescue:

Now lets enable the paging file. Process 1 wants yet another byte of memory. The operating system will guess (occasionally incorrectly), which byte(s) are least likely to be needed by the programs in the near future, and pages, it saves the contents to disk and it marks that physical block of memory as free, and marks the virtual address as invalid. It keeps track that it has done this. Now, it has a free block of memory that it can give to process 1, and map it in its virtual address space. Think of it like boxing up your winter clothes to make room on your shelf for your khaki shorts an ankle socks. 

I hear those of you at the back of the class are snickering, "but what happens when process 1 accesses byte 0?". Well, smarty, glad you asked. The CPU will raise a hardware level error "invalid memory address" when process 1 reads byte 0, which was paged to disk. The operating system intercepts the error before the process is aware of it, and realizes that process 1 needs that byte loaded back into physical RAM, and remapped. What if there is no free RAM? Then the operating system has to find a different byte and pages that one out first. As you can imagine, this is substantially slower than if the byte was already in RAM. 

So what the fine folks that made the femto computer OS decided was, "we're going to try to keep a certain number of bytes free when possible, so that new bytes can be allocated quickly". When the computer idles later, it will find some new bytes to page out, to keep more physical RAM free. The operating system then is free to use that RAM for caching frequently used files. That makes performance better. 

Doing it wrong.

So now let's suppose that some femto computer enthusiast got the bright idea "all that paging to my hard drive/SSD is really slowing my machine down. If the page file were on a RAM disk, that should make it faster." Let's take a look at what that looks like:

Now, the system still has to do all the work it had to do before, paging to "disk", in this case an RAM disk. But we're pretty much back to where we started in the beginning, you can never have more memory allocated to programs than the amount of physical RAM. But now, the OS has to work a lot harder to manage it. The system also has a lot less "playing room" , and forget about caching files, there's no room, so we must go to disk for all file access. 

The solution

Leave RAM alone. Modern operating systems are all very good at taking care of this transparently. If you have a Windows/Linux/Mac machine, they all work like this, though each may have variations in the implementation. If your system is "too slow" because of excessive paging, it is not a page file problem, it is a "too many programs" or "not enough RAM" problem.

To use the wardrobe metaphor, paging to a RAM disk is like boxing your winter clothes to make room on your shelf, and then storing those boxes on the shelf itself. 

All that being said, there are ways to make paging faster. Most involve putting the page file on a different and/or faster drive. 

--P