C++: Limiting CPU usage intentionally

Question

At my company, we often test the performance of our USB and FireWire devices under CPU strain.

There is a test code we run that loads the CPU, and it is often used in really simple informal tests to see what happens to our device's performance.

I took a look at the code for this, and its a simple loop that increments a counter and does a calculation based on the new value, storing this result in another variable.

Running a single instance will use 1/X of the CPU, where X is the number of cores.

So, for instance, if we're on a 8-core PC and we want to see how our device runs under 50% CPU usage, we can open four instances of this at once, and so forth...

I'm wondering:

1. What decides how much of the CPU gets used up? does it just run everything as fast as it can on a single thread in a single threaded application?

2. Is there a way to voluntarily limit the maximum CPU usage your program can use? I can think of some "sloppy" ways (add sleep commands or something), but is there a way to limit to say, some specified percent of available CPU or something?

Answer 1

CPU quotas on Windows 7 and on Linux.

Also on QNX (i.e. Blackberry Tablet OS) and LynuxWorks

In case of broken links, the articles are named:

• Windows -- "CPU rate limits in Windows Server 2008 R2 and Windows 7"
• Linux -- "CPU Usage Limiter for Linux"
• QNX -- "Adaptive Partitioning"
• LynuxWorks - "Partitioning Operating Systems" and "ARINC 653"

Answer 2

1. The OS usually decides how to schedule processes and on which CPUs they should run. It basically keeps a ready queue for processes which are ready to run (not marked for termination and not blocked waiting for some I/O, event etc.). Whenever a process used up its timeslice or blocks it basically frees a processing core and the OS selects another process to run. Now if you have a process which is always ready to run and never blocks then this process essentially runs whenever it can thus pushing the utilization of a processing unit to a 100%. Of course this is a bit simplified description (there are things like process priorities for example).
2. There is usually no generic way to achieve this. The OS you are using might offer some mechanism to do this (some kind of CPU quota). You could try and measure how much time has passed vs. how much cpu time your process used up and then put your process to sleep for certain periods to achieve an approximation of desired CPU utilization.

Answer 3

You've essentially answered your own questions!

The key trait of code that burns a lot of CPU is that it never does anything that blocks (e.g. waiting for network or file I/O), and never voluntarily yields its time slice (e.g. sleep(), etc.).

The other trick is that the code must do something that the compiler cannot optimize away. So, most likely your CPU burn code outputs something based on the loop calculation at the end, or is simply compiled without optimization so that the optimizer isn't tempted to remove the useless loop. Since you're trying to load the CPU, there's no sense in optimizing anyways.

As you hypothesized, single threaded code that matches this description will saturate a CPU core unless the OS has more of these processes than it has cores to run them--then it will round-robin schedule them and the utilization of each will be some fraction of 100%.

Answer 4

The issue isn't how much time the CPU spends idle, but rather how long it takes for your code to start executing. Who cares if it's idle or doing low-priority busywork, as long as the latency is low?

Your problem is fundamentally a consequence of using a synthetic benchmark, presumably in an attempt to obtain reproducible results. But synthetic benchmarks tend to produce meaningless results, so reproducibility is moot.

Look at your bug database, find actual customer complaints, and use actual software and test hardware to reproduce a situation that actually made someone dissatisfied. Develop the performance test in parallel with hard, meaningful performance requirements.