Linux reported load averages, for example from top and uptime commands, can be incorrect either too high or low. WWW.Smythies.com
Note (2012.06.24): Tests results page for another proposed patch to improve Reported Load Averages.
This web page is with respect to kernels with load calc changes as per Commit-ID: c308b56b5398779cd3da0f62ab26b0453494c3d4.
Follow this link for the web page about reported load averages sometimes being massively too low. (i.e. prior to the above referenced commit). Review of that page is highly recommended.
The problem: The above referenced commit was included in the Ubuntu Precise Pangolin 12.04 LTS release, and is being propagated to other kernel.org kernel branches.
Now complaints are being raised about "high load average on Ubuntu 12.04 under idle conditions".
Incorrect high reported load averages can be reported under conditions of light load and high enter/exit idle frequency conditions (greater then 25 hertz).
This condition is most apparent with Ubuntu desktop edition.
Over the entire operational space of all loads and all idle enter/exit frequencies and all number of processes, the reported load averages are better than they were before the above referenced commit.
It is not clear if there is a solution within the current context of how load averages are calculated with tickless kernels.
Test results: (Where available, some graphs can be "clicked" on to go to a more detailed write up of the experiment that provided the plotted data):
First, some review graphs from before this commit, where the issue was very low reported load
averages:
The issue was that the reported load average would be zero if the enter/exit idle rate was above
25 hertz (for a kernel with a basic tick rate of 250 hetrz)

Resulting in reported load average errors for 25 hertz and above as detailed below:


Next, a control sample with a kernel compiled with CONFIG_NO_HZ=n (i.e. tick as opposed to
tickless)


Now, with the commit version of the kernel.
Note: CPUs forced to always stay at the lowest frequency, "powersave", mode.
Note: It was important to understand the total idle enter/exit frequencies, because often, it seems, under
low load multiple processes are piled onto one CPU.
Some tests were re-done with only one process.
The worry is that under very light loads, other background tasks can no longer be
ignored and might be biasing the results.
Note: While errors bars are not shown, sometimes they would be rather large.
First: Frequency sweep, one process, actual load ~0.20:

Detail B:

Now observe reported load averages as a function of processes and actual loads.
Before the commit, every data point in the below graph would be at a reported load average of 0.0
Idle enter / exit frequencies were selected to always add up to 180 hertz and also to avoid going
below 25 hertz and avoid the 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.

Hopefully the above graph makes it obvious where the recent complaints of high reported load averages
have been coming from.
Next, take one condition from above and check more frequencies. The one process case was done:
Before the commit, every data point in the below graph would be at a reported load average of 0.0

For further reference and comparison, the exact same experiment, but with a tick based kernel (CONFIG_NO_HZ=n):

Detail A:

Conclusions: Reported load averages are improved for conditions of medium to high actual loads
and higher idle enter/exit frequencies.
Reported load averages are in error, too high, and somewhat independent of actual load for conditions of lower actual loads and idle enter/exit frequencies above 25 Hz (for kernels with a basic tick rate of 250 Hz). The complaints that are being raised are related to the actual low load average case, and is compounded by the point of reference, the non-commit kernels, being in error on the low side. Even the tick based (CONFIG_NO_HZ=n) kernels tend to report load averages on the low side of actual the actual load.
References:
The launchpad bug that I added to.(main reference)
The newer launchpad bug complaining of high load averages with the patch.
Another newer launchpad bug complaining of high load averages.