Can a process that needs 15 MB run given a machine with 10 MB of physical memory and 10 of virtual?

Question

So there is physical and virtual memory. Let's say we have 10 MB physical and 10 MB virtual.

There is also paging. As far as I get it, paging basically splits physical and virtual memory into slots of the same size. Such slots are called frames. So if we use slots of 1 MB, we will have 10 frames in physical memory and 10 in virtual memory.

A process requires memory, and all such memory must be located in the physical side. If we load a process that needs 5 MB, then 5 frames in the physical side will be claimed for it.

If the process requires 15MB, then... 10 frames in physical memory are claimed, and 5 in virtual? But the process needs ALL its memory in the physical side, right? So the first question is:

• Does this mean that a process that needs 15 MB cannot run on our machine, since only 10 MB fit in the physical side?

Alright. Let's say we have two processes. Each needs 8 MB. 8 frames in the physical side will be claimed for the first process, and 2 frames for the second. Then 6 frames in the virtual side will be claimed for the second.

Only one process can run at a time, so when it is the second process' turn, it needs to retrieve its 6 frames from the virtual side to the physical side. This will cause 6 frames of the first process to move from the physical side to the virtual. Is this correct?

Answer 1

The entire point of virtual memory is to be able to run processes that require more RAM than you have RAM chip in your computer. If it couldn't do that, you wouldn't be any better off than without it.

As Robert Harvey has explained, the way of providing this capability is to intercept all memory accesses the process makes and loading them into physical memory as required. This works because even a process that requires a certain amount of memory will never actually read all of that memory simultaneously, so the OS, which already controls execution speed of that process via time-slicing, can also control the memory use of that process by only providing the bits it does actually access in any given time slice, rather than all the bits that it could access if it decided to.

Answer 2

The important thing to understand about virtual memory is that it's, um, virtual.

For example, a process might think it has 20 MiB of virtual memory. However, 5 MiB of that might be part of a memory mapped file that hasn't been loaded from disk, 5 MiB might look like a large area that's full of zeros (but might be the same tiny area full of zeros repeated over and over and over), 5 MiB might be data on the swap partition.

It's all virtual, which means it all looks like RAM is there (even when it's not).

When the process tries to access something that actually isn't there, the kernel is notified (e.g. "page fault") and does whatever it needs to do to maintain the illusion that the RAM was there all along.

For example, if the process reads some data from the area that's actually a memory mapped file, the kernel might load 4 KiB from the file into memory and let the process think the data was always there. If the process writes to that big area full of zeros then the kernel might allocate a new small area (and fill it with zeros) that the process can modify (without messing up other areas of zeros). In the same way, if the process tries to read/write to something that's currently in swap space, the kernel fetches it from swap.

To make this happen, the kernel might need more memory. When it runs out of memory, the kernel can just copy data to disk/swap space and re-use that memory. Of course if a copy of the data is already on disk (e.g. it wasn't modified since it was loaded from disk last time) the kernel doesn't even need to do that - it can just re-use the memory immediately.

So... You might have a process with 2 GiB of virtual space. In that 2 GiB of space the process might only be using 50 MiB of virtual memory. Of that 50 MiB of virtual memory, it might only be 10 MiB of actual RAM (and 40 MiB of "trickery").

Of course (because disk IO is slower than RAM) most of the tricks do effect performance. Kernels try to be smart and try to keep the "most likely to be used" data in memory to minimise the effect on performance. Sadly, predicting the future is hard, so "trying to keep the most likely to be used data in memory" typically ends up being more like "actually keeping the most recently used data in memory".

In any case, the best way to minimise the overhead is to have enough RAM. The more RAM you have, the less trickery the kernel needs to do, and the faster things go. Fortunately, most of the memory that most processes use isn't actually used very often, so (depending on the process) you can get by quite well with only half the RAM.

Also note that (in general) worse performance might be undesirable, but it can be a whole lot better than "process crashed due to out of memory".

Answer 3

It could run in theory, but the ratio 15/10 is significant enough to probably make thrashing happens. If that is the case, the process could run many thousand times slower (because too often the kernel would fetch some page from the disk and pageout another page); if your disk is still a real rotating disk (not an SSD) it would make a lot of noise. Definitely, read the wikipage about virtual memory.

On some OSes, you could give hints to the virtual memory subsystems. For example, using madvise(2) on Linux, and posix_madvise on POSIX.

In practice, today's disks are so slow w.r.t. CPU and RAM (about a million times slower) that it does not make sense to have a working set larger than the available RAM. This was a bit less true in the 1980s (because at that time the speed ratio RAM vs disk was less high). I remember having (painfully) - circa 1987 - run a Lisp process of 15Mbytes on a 12Mbyte Sun3 : the disk (of the size of a washing machine) was vibrating a lot. The process ran about 20 times slower.

Read also about memory overcommit and http://linuxatemyram.com/

And today, the CPU cache matters a lot, perhaps even more that the page cache.

BTW, you could do some experiments on Linux, since you can limit the RAM used by a process (using setrlimit(2))