Is virtual memory always available?

Question

Principles of virtual memory:

The idea of virtual memory is to create a virtual address space that doesn't correspond to actual addresses in RAM. The system stores the official copy of memory on disk and caches only the most frequently used data in RAM. To make this workable, we break virtual memory into chunks called pages; a typical page size is four kilobytes. We also break RAM into page frames, each the same size as a page, ready to hold any page of virtual memory.

I'm running a Linux system and the swap area is empty, because there's enough space in main memory. That being said, is there still a virtual memory with pages and will processes continue to have virtual addresses instead of the physical addresses of their segments in the main memory?

What if there's no swap area in disk, is there a virtual memory in the system too?

In simple words, is virtual memory always available in a Linux system and will process always have virtual addresses?

Answer 1

Virtual memory (paging) is enabled on CPU level. That means CPU uses MMU to convert virtual address (as it seen by application) to physical address. Memory is split to pages. Page could be either loaded to memory or loaded to disk. If page is on disk then accessing this page leads to page fault which is processed by OS (OS loads page from disk).

So if you have no swap you still have virtual memory, CPU still uses MMU and splits memory into pages but OS can't move those pages to disk.

http://wiki.osdev.org/Paging

Answer 2

No.

As mentioned by user996142, there are two things called virtual address space. However, the definition you show in your question more specifically talks about the swap space. Either way, I think both statements are rather convoluted.

At the CPU level, you need to have an MMU to have what is called virtual memory addresses. As mentioned by the other user, the computer has physical memory which are given physical addresses. In most cases, physical memory starts at 0 and grows up to the total amount of memory you have. Some architectures like to have memory at the end as well (at addresses -1, -2, -3...) All CPUs do not have MMU chips, especially in embedded systems. Some such systems still use 8 bit CPUs which really can't be using an MMU (these are limited to 64Kb addressable memory anyway).

At the system level, the virtual memory is the swap as you mentioned. Again, this is not necessarily available. In most distribution of Linux, a swap is automatically created at installation time. However, there are systems that do not do it automatically (for example, DigitalOcean offers machines with Ubuntu which do not offer swap space by default...) In most cases, having some swap is a good thing to avoid having processes killed by the OS to restore RAM (and as a result, you have no clue what just happened).

The kernel is responsible for managing all of that for you.

The MMU part is a very low level. For most implementations, it is required to run processes under Linux. Without that feature, you either need processes that can run at any location (that was a fun thing on old Macs running on 68K processors, you'd create blocks of code that were around 64Kb that could be placed anywhere in memory), or have a way to relocate the process...

Note: For a while now, the Linux kernel was updated to not run processes at the same IP address on each restart. It's really annoying if you are trying to debug your own process and would like to rely on such fixed IP addresses. But this is much more secure. As a result, though, just the MMU is not sufficient to run processes. They have to be relocated on each restart depending on the IP chosen by the kernel at that point.

The swap is a much high layer which allows you to run processes that make use of way more RAM than you have on your computer by putting some of the data on disk. There is a huge penalty in term of speed, of course. In most cases, it's better to run one process, and once it is done, run the next process, etc. to avoid swapping to disk.

As an important aspect, the code of a process (the assembly code, for interpreted languages such as python and php, that would be the interpreter binary) is not changing and available on disk in read-only mode. What that means is: you can swap out part of the code of a process and reload it later as required without the huge penalty of having to swap data found in RAM. Data has to be written to disk and that's slow. Code only needs to be read. So if part of a process code is never executed, that page of code can be swapped out very quickly and reloaded in case it happens to be executed again later. That swap doesn't need the swap disk or swap file. So even if your swap space is 0Kb, the kernel can still swap out the code of running processes to save some RAM.

Answer 3

If linux is running on a cpu with a memory management unit (MMU) then virtual memory is always in use.

The term "virtual memory" has two meanings here that are entangled. It could refer to the virtual assignment of memory addresses within a process that may or may not correspond to physical memory. It can also refer to disk blocks that are available to expand memory space beyond what is physically available as ram by mapping them to process virtual memory.

Linux (and unix in general) is demand paged, meaning pages are loaded from disk or allocated from the free memory pool on demand.

Pages in a process can be in multiple states from multiple sources:

• An executable page most likely is associated with a program or shared library on disk. There is a copy of this page on disk, and possibly a (read only) copy of this page in physical ram. These pages may be shared (read only) by all processes using the files in question.
• A data page for the process may be in physical ram. If it is in ram, it may be clean or dirty. A clean data page has a copy in swap (and could be released if needed). A dirty page either has no copy in swap, or the page has been modified (and the swap page released). It may also be swapped out, with no copy in physical ram.
• A file on disk can be mmap'ed into virtual memory for the process. Executable pages are mmaped read only (described above). But it is also possible to mmap a writable file as a data page, and then it is saved to the file instead of swap. When a mmaped data page is dirtied, it will be opportunistically written back to the file shortly. As above, a mmaped page can be on disk only or duplicated in ram (clean or dirty).
• A page can also be allocated in virtual memory, but with no corresponding data either in physical ram or on disk. This happens when a process requests more memory but hasn't (yet?) used it. A read from such a page will return zeros. A write will cause a physical page to be zeroed, assigned to the process, and then the write will complete. (Or, the process will be killed with an out of memory error if this isn't possible.)

So if there is no swap, there still is virtual (non-physical) memory used for empty uninitialized pages, executable pages, and there can also be mmaped data pages. Also, physical memory is included in virtual memory, with or without disk backing.

The difference is that without swap, when the system runs short on memory, read only pages will be flushed frequently to load other pages, and unless associated with a file (mmaped or not), dirty pages have no where to go and are locked in physical memory.

This oversimplifies things slightly, as there are also cached pages of disk files that are not assigned to any process's virtual memory but still involved in the virtual memory system. Also the implementation details may order some of the above described operations differently.

Note that older unix systems required enough swap space to back all physical memory pages, so swap was typically at least twice the size of ram. Linux abandoned this strategy very early on, and doesn't require any swap.