An Experiment to determine Linux reported load averages Vs. Actual loads for N processes. WWW.Smythies.com
This page is for Ubuntu Kernel 3.2.0-29, which contains the backport of the patches. This is just a check experiment and the results should not differ from the "peter35" test kernel (and they do not differ).
This web page provides the details for the data that gives this graph:

The experiment was done on a Ubuntu server 12.04 running the kernel with the various load average fixes applies, 3.2.0-29.
With older kernels prior to commit c308b56b5398779cd3da0f62ab26b0453494c3d4, every data point in the above graph would be at a reported load average of 0.0
With newer kernel, prior to this patch, high reported load averages can occur at light loads with high context switch frequencies and low reported load averages can occur at high loads and extremely high context switch frequencies.
Idle enter / exit frequencies were selected to always add up to 180 hertz and also to avoid going below 25 hertz and avoid known alias frequencies.
This gave: 6 processes at 30 hz; 5 processes at 36 hz; 4 processes at 45 hz; 3 processes at 60 hz; 2 processes at 90 hz; and 1 process at 180 hz.
To avoid discontinuities in the reported load averages, and to maintain predictable execution loop times in the main program, the cpu frequency governors were set to powersave mode.
The main program, as a text file.
The program, as a text file, that generates the script for execution conditions of the main program.
The resulting script, as a text file, edited for one hour (4 time constants of the 15 minute load average) of extra settling time between number of processes changes.
The raw data as a text file.
The oversampled data as a text file. (warning: large file ~ 3 megabytes)) Sometimes used to correct bad data or outlyer samples.
The main program parameters were selected to print an update every 10 seconds and to run for 30 minutes.
Obviously, the server can not be used for anything else during the execution of this test, or the reported load averages might be biased. See the background (idle) results which verifies that the background can be ignored.
For the 5 and 6 processes cases, the reported load averages are in error at higher loads, even more in error than the previous solution. Why?
This appears to be the area where the use of the CPU's begins to rotate around somewhat. At lower loads, the use of CPU's doesn't change very "often".