Why turning off Virtual Memory doesn't improve my computer's performance?

Question

I'm studying computer architecture, more specifically, virtual memory. One thing that I can't seem to uderstand is why turning off Virtual Memory doesn't improve my computer's performance?

I know there are some downsides to disabling virtual memory (Windows won't be able to create crash dumps, for example), but shouldn't it speed up my system?

If I'm using Virtual Memory, for every access to RAM my MMU have to make another access to the main memory (or at least to TLB) in order to translate my virtual address to a hardware adress (right?).

So, assuming I have plenty of RAM, shouldn't disabling Virtual Memory prevent this aditional access to memory (since I no longer have to translate my address from virtual to physical) and thus speed up my system?

Solution 1

Because virtual memory is more than just the page file.

You have simply removed the storage device that allows your system to push memory out to disk and you cannot "just" disable virtual memory on a modern operating system.

Operating systems use virtual memory to enforce security by segregating applications into their own address spaces.

By giving applications their own address space every application has access to their entire address range without having to fight other applications for memory regions.

Memory segregation and copy-on-write protections mean that a two applications could be sharing the same libraries and using nearly the same set of code, but are entirely protected from one another. One program crashing or doing something it shouldn't will not cause the other program to die as well.

Your system is always using virtual memory, because it is a key component in any modern operating system design.

Solution 2

why turning off Virtual Memory doesn't improve my computer's performance?

When you do this in Windows, what you really do is disable the page file. You tell the OS that it should no longer evict what it thinks are lesser used pages to disk temporarily.

This can actually slow your computer down as it keeps stuff that might not be used very much in RAM, as opposed to on disk and swapped in when needed.

This does not disable the MMU. The MMU is used and needed at all times while the system is running in protected mode to implement process separation, the "NX" feature which prevents data in a page from being executed as code, and other features.

---

Any memory access is going to be slower than on-chip functions. This was one of the considerations when RISC-type CPUs were developed - put a bunch of registers on the chip so RAM can be accessed less.

One of the improvements that was introduced with AMD64 CPUs were adding more registers, meaning it's possible to do more without using RAM as a scratchpad. Modern CPUs also have a bunch of very wide SIMD/AVX/EVEX registers as well. There's lots of non-RAM options for computation on modern x86 CPUs.

And anyway, unless disabled, CPU RAM accesses are going to leverage the internal L1 cache first anyway, which is very fast since it's literally on the same die as the CPU.

Any speed gain you have by disabling the MMU/TLB is going to be very small and you won't be able to protect memory from other processs.

Solution 3

You will not outsmart your Operating System's Virtual Memory Management, be it Windows, Mac, or Linux.

The OS will not store data in a page/swap file unless absolutely needed. You should not see a performance impact from having a pagefile enabled, as it is only used as needed, in the background.

If your computer is hitting the page/swap file so often that your computer slows down, removing that won't help anything, it will just cause your applications or OS to crash when you run out of RAM.

Additionally, disabling the page/swap file does NOT disable "Virtual Memory". Virtual memory is a memory addressing concept that allows for paging/swapping, but it is still used regardless of whether you enable a pagefile or not.

Solution 4

Intel CPUs can run in two addressing modes and are capable of switching between them:

Real mode

Real mode is characterized by a 20-bit segmented memory address space (giving exactly 1 MiB of addressable memory) and unlimited direct software access to all addressable memory, I/O addresses and peripheral hardware. Real mode provides no support for memory protection, multitasking, or code privilege levels.

Protected mode

protected mode, also called protected virtual address mode, is an operational mode of x86-compatible central processing units (CPUs). It allows system software to use features such as virtual memory, paging and safe multi-tasking designed to increase an operating system's control over application software.

Conclusion : Modern operating systems use Protected mode. Only the kernel ever uses Real mode to directly access the hardware. To turn off Virtual Memory you would need to write your own operating system, which wouldn't anyway be capable of using the entire power of the CPU. I suggest to re-enable the page file so Windows could function normally, as this file has no connection to the addressing mode of the CPU.

Read the Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volume 1 and especially the section of "Switching Back to Real-Address Mode". Back to school, friend.

Solution 5

There are several correct points in the answers so far but an important point has been missed.

As others have stated, disabling the pagefile does not turn off virtual memory. Address translation (through page tables) and everything we get from that (separate process address spaces, per-page read/write and kernel/user memory protection, the "no-execute" bit, etc., etc.) will still be happening.

What no one has brought up yet is that disabling the pagefile does not turn off paging IO either. Paging to and from disk will still be happening, even if you have no pagefile. This is trivial to demonstrate, at least on Windows. Disable your pagefile, reboot, start up Performance Monitor (perfmon.exe), look at the Paging IO counters under the memory object, and start running some programs.

How can that be? Because the pagefile is not the only file involved in paging or in paging IO!

What other files are involved in paging IO? Mapped files. And "mapped files" includes all code files - on Windows, primarily exe's and dll's.

When you start running a program or load a dll into an existing process, the code is not simply copied in its entirety into RAM. (The Windows API name "LoadLibary" notwithstanding.) The code file is simply mapped into your address space. It's the pager that does the reading, and it does so in response to page faults. The page faults happen as instructions are being fetched from code pages that are not yet paged in. In other words, code is demand paged into RAM like everything else in virtual memory (ie large portions of your code that don't actually get executed aren't brought in).

(I'm omitting mention of the prefetcher here, but that really doesn't change the principles described. Code is still demand-paged, the prefetcher just tries to make it happen sooner within the life of the process.)

And if some code is paged in, and RAM later gets scarce and some already-paged-in stuff needs to be "evicted" from RAM to make room for new stuff, pages containing code are just as subject to being paged out as data pages.

The only difference is that pages containing code are not often changed once in RAM, and if they haven't been changed, they don't have to be written anywhere before they are repurposed for something else. If they're reclaimed by the memory manager, and then later needed again, they can be (and are) just paged back in from the exe or dll files they came from.

Data files, especially large ones, are often accessed via file mapping too. The relevant *nix call is mmap(), in Windows it's CreateFileMapping or OpenFileMapping, and MapViewOfFile. Such mappings are often read/write. And if pages in such mappings have been modified while in RAM, then when the pages have to be evicted from RAM, they're written back to their original files. The pagefile is not involved.

Unless they were mapped as copy on write. Which I won't detail here, except to say that they're backed by the pagefile, if you have one.

For a given workload and a given amount of RAM there will be a certain amount of paging. Turning off the pagefile just means that all of it will be to mapped files, instead of some to mapped files and some to the pagefile. But it will still be happening. So you see, there will still be just about as much paging IO without a pagefile as with.

That's why turning off the pagefile doesn't affect performance much.

In fact, it can make things worse. Without a pagefile, when paging to disk has to happen, it has to happen to mapped files. Result: every not-shared page that every process has ever modified has to be kept in RAM until the process that modified it exits. Including old stale stuff at the bottoms of stacks, etc., that will likely never be referenced again. The pager just can't consider those pages for eviction (no matter how good a choice they would be) because there is no other place to store their contents.

btw, page writing is not usually much of a bottleneck. Writing to the pagefile, or to mapped files, is practically free (app code doesn't have to block while it happens; it's run in a separate thread). What slows down your real work is when the pager has to read the disk - ie when it has to resolve a hard page fault. Of course this can happen to both the pagefile and mapped files (including code files) - whatever the backing store for the faulted-to page is.

Again: The paging IO counters in Windows will tell you how much paging IO is happening. And they will not be zero without a pagefile.

As for the aspect of he OP's question that pertained to avoiding the overhead of address translation, reading page table entries and the like - the overhead is extremely small. It's been measured at less than 2%. The reason for this is that the Translation Buffer (TLB) cache does what it is supposed to.

View more solutions

Comments

[phuclv]

virtual memory is not always used

[appa yip yip]

@phuclv But even when it is not used, the MMU still have to translate the address, doesn't it?

[Daniel B]

You cannot deactivate virtual memory. Simple as that. It is part of how process separation and whatnot works.

[zymhan]

Yes the MMU will always translate addresses, as no Operating system since DOS uses actual physical memory addresses.

[Christopher Hostage]

This is an excellent question for your professor. You can spend multiple semesters at college figuring out how different OSes handle virtual memory.

[Giacomo1968]

“…why turning off Virtual Memory doesn't improve my computer's performance?” In “Ye Olden” days of Connectix RamDoubler on a Mac, maybe that would work. But not on a modern OS by a longshot.

[phuclv]

by "Virtual Memory" above I actually mean page file Swapping, Paging, Segmentation, and Virtual memory on x86 PM architecture

[appa yip yip]

can someone explain why is this question being downvoated?

[Austin Hemmelgarn]

I would like to point out that depending on the exact workload, you may actually see a performance improvement on Windows by either down-sizing or completely disabling the page file. Windows has a very aggressive VM subsystem that has a strong tendency to push things out to the page file when they don't need to be. It has been getting significantly better about this recently, but it's still way more aggressive than Linux or Mac.

[Jamie Hanrahan]

@AustinHemmelgarn Your claim about Windows is not true. Many people think it is because Windows XP's Task Manager reported potential page file usage - as if it was actual pagefile usage (the "PF usage" graph). That graph should have been labeled "commit charge". And no version since has made the actual pagefile usage as evident as it should be, given how many people fret about it. But most people who look at the performance counter "% pagefile usage" will find that not nearly as much is in the pagefile as they thought.