How to Prevent Paging for One Program/Process

How to prevent paging for one program / process?

At the start of the program, call:

mlockall(MCL_CURRENT | MCL_FUTURE);

(If you do not have the source to the program, you'll have to debauch the process with ptrace to do this).

Be aware that this will increase the chances of memory allocations made by the process failing.

Disabling pagefile just for an application?

You can use VirtualLock to lock a specified region of the process's virtual address space into physical memory, ensuring that subsequent access to the region will not incur a page fault.

How to use dynamic data structures like std::vector and prevent paging ?

1, 2, and 3 are all correct, assuming that 2 refers to portable ways. You can make a decent guess based on OS-specific process memory usage reporting functions. They're not that accurate and they're not portable, but they do offer a fairly good guess.

As for 4, that's just not true. It is a function of the amount of physical memory compared to the virtual address space size of the process. x64 has a way larger address space than there is physical memory. x86 is substantially smaller now but go back a few years to older machines with 2GB or 1GB of RAM and it would be bigger.

If you need to write some algorithm and be sure that there will be no
paging, do not use dynamic data structures like std::vector. Instead
use an Array and make sure it will stay in memory using OS-specific
functions like for example mlockall (Unix)

Bullshit. You can reserve the vector to allocate all the memory you need, then call mlock anyway.

But there is most certainly no OS-independent way to write a program that will not cause paging. Paging is an implementation detail of the flat memory model used by C++ and there is certainly no Standard functionality relating to this implementation detail, nor will there ever be.

Can I tell Windows not to swap out a particular processes’ memory?

You can use VirtualLock to prevent memory from being paged to disk, but I really think you're better off letting the OS manage the system's memory. It's pretty good at it, and I wouldn't second guess why the OS was swapping things to disk unless I really knew what I was doing.

How does using paging method in OS justify its overhead?

Paging is the basis for various "virtual memory tricks", like:

• instead of having to wait while a file is loaded before it can be used; mark the pages as "belonging to a memory mapped file" and then pretend that the file was loaded (and fetch the pages from disk when they're actually needed, possibly with some pre-fetching strategy happening in the background). This reduces RAM consumption and can speed up things like executable start-up times.

• instead of allocating actual physical RAM during things like process start-up (for its ".bss section"/uninitialized data, "not used yet" heap space, etc), and instead of literally copying all pages during fork(); use "copy on write" tricks so that you only need to create/copy the data when it's actually modified. This reduces RAM consumption and speeds everything up (especially when a lot of the memory is never modified).

• if there isn't enough RAM, then you can just send pages to swap space (e.g. disk) and keep everything running. This is much faster than waiting for something to happen that will never happen (because the process crashed due to not having enough memory).

• all of the things above that reduce the amount of actual RAM being used mean that you can use that RAM for file system caches instead. Significantly larger file system caches can mean significantly faster file IO (less "file cache miss", less slow disk IO). Of course if data is in file cache you can map the same pages as "copy on write" into multiple different processes too (without copying the data or using more RAM).

For overhead; CPU manufacturers put a lot of effort into minimizing the overhead (using "translation look-aside buffers", pre-fetching strategies, out-of-order execution to keep CPU busy while it waits for a translation to happen, etc). In the same way, operating system developers also try to minimize the overhead (e.g. reduce the number of task switches between processes, trying to keep processes on the same core, etc). This means that the overhead is fairly small compared to the many large benefits.

Of course without paging you end up having to deal with external fragmentation, which typically devolves into wasting lots of CPU time copying large amounts of data from one piece of RAM to another to "de-fragment" RAM. On top of that, you'd need something else to ensure that different processes are isolated and that any permissions (like "this area is not executable") are/can be enforced; and this "something else" will probably add as much overhead as paging all by itself (unless you want a massive security disaster). With this in mind, even if you ignore the benefits of paging, paging is still likely to be less overhead than not using paging.

The thing that I don't understand is why can't we just divide a program into an arbitrary number of segments each time we load it into operative memory.

Dealing with different segment sizes would be painful (less "shift and mask to find the right index in a table" and more "do a linear search through all segments to find the right segment"). If you use fixed sizes segments it would be much faster; but that's what paging is (a "page" is your "fixed size segment").

Disabling swap (paging file) to ensure everything is really in memory

There is one thing that you cannot force into memory by doing that: Executable images and mapped files. Those are a each "page file" of their own. When memory pressure occurs Windows detects that their pages in memory have not been modified and just discards those pages because they can be reloaded later.

Everything that is not file-backed cannot be paged out (there is just no place to put it). So I guess your technique would work in practice.

You won't see a lot of problems. I am running without paging file all the time (16GB RAM). You loose the ability to capture full memory dumps in case of a blue screen but most likely you don't need that.

Just make sure that you never hit the physical memory limit or else a lot of programs will crash hard. Nobody writes their programs to cope with OOM situations (except core Windows components which I never have seen crash from that. Good job by them.).

---

Related Topics