How to write a C or C++ program to act as a memory and CPU cycle filler?

Question

I want to test a program's memory management capabilities, for example (say, program name is director)

1. What happens if some other processes take up too much memory, and there is too less memory for director to run? How does director behave?
2. What happens if too many of the CPU cycles are used by some other program while director is running?
3. What happens if memory used by the other programs is freed after sometime? How does director claim the memory and start working at full capabilities. etc.

I'll be doing these experiments on a Unix machine. One way is to limit the amount of memory available to the process using ulimit, but there is no good way to have control over the CPU cycle utilization.

I have another idea. What if I write some program in C or C++ that acts as a dynamic memory and CPU filler, i.e. does nothing useful but eats up memory and/or CPU cycles anyways?

• I need some ideas on how such a program should be structured. I need to have dynamic(runtime) control over memory used and CPU used.
• I think that creating a lot of threads would be a good way to clog up the CPU cycles. Is that right?

Is there a better approach that I can use?

Any ideas/suggestions/comments are welcome.

Answer 1

http://weather.ou.edu/~apw/projects/stress/

Stress is a deliberately simple workload generator for POSIX systems. It imposes a configurable amount of CPU, memory, I/O, and disk stress on the system. It is written in C, and is free software licensed under the GPLv2.

The functionality you seek overlaps the feature set of "test tools". So also check out http://ltp.sourceforge.net/tooltable.php.

Answer 2

If you have a single core this is enough to put stress on a CPU:

while ( true ) {
   x++;
} 

If you have lots of cores then you need a thread per core.

You make it variably hungry by adding a few sleeps.

As for memory, just allocate lots.

Answer 3

There are several problems with such a design:

1. In a virtual memory system, memory size is effectively unlimited. (Well, it's limited by your hard disk...) In practice, systems usually run out of address space well before they run out of backing store -- and address space is a per-process resource.
2. Any reasonable (non realtime) operating system is going to limit how much CPU time and memory your process can use relative to other processes.
3. It's already been done.

More importantly, I don't see why you would ever want to do this.