Force a process to run in virtual memory? Ubuntu

Question

I am running a series of tests for an implementation of a remote pager that sends page faults to other computers in a network.

Long story short, I was wondering if there is an easy way to force a process to use virtual memory as oppose to physical RAM so that I can better measure the performance of my implementation against how the system would perform while swapping to the hard drive.

Answer 1

This is difficult, but what you essentially need is for a separate process to consume all of the available RAM, locking its own data into physical RAM, but leaving all of the swap available (you should be able to see the effect using the 'free' command)

I think there are already tools out there to do this (I don't recall any specific examples, but there are tools to fill up memory or test memory for bit errors while the system is running... that type of thing) or something close to it.

My question is ... why? Why intentionally cripple the test machine only to get number that is highly specific to your swap configuration (disk type, size, rotation rate, etc)? Also, how resource intensive is your application in the first place? If it isn't very (say a meg or two of RAM), then swapping won't hurt very badly.

Answer 2

well to be clear, RAM is part of the virtual memory hierarchy

it isn't possible for a process to bypass RAM...how would swapped pages re-enter the CPU cache?

you can simulate something like it by having a box with ridiculously low RAM, but even then you can see from vmstat that it is still being used, and used in a nondeterministic way with regards to your test set

Answer 3

You can limit the amount of physical RAM available to a process with ulimit -m. Note that ulimit is a shell builtin, documented in the shell man page (man sh or man bash). For example, the following snippet limits the program to 400kB of physical memory:

(ulimit -m 400; exec /path/to/application)

The underlying interface is setrlimit(RLIMIT_RSS, …). The manual page states that this limit is not supported on 2.6 kernels, but I think it's obsolete as RLIMIT_RSS does appear to be used by current 2.6 kernels.

Answer 4

It sounds to me like he wants to test that the pager message gets out even when the machine being monitored is bogged down with heavy swapping. This is a reasonable test case.

I'd probably set up a program that allocated lots of memory and does random reads and writes throughout that memory, making sure each address is a different page. Run a few copies of this, and a few copies of a video compression job for eating up CPU cycles - that should make the machine busy.