www.smythies.com
doug user account web pages. (parent page of parent page)
doug network related notes. (parent page)
Linux reported load averages web pages (this page).
.
Original Linux Reported Load Averages can be way too low.
Linux Reported Load Averages can be too high under light actual loads. (and, it turns out, too low under very high load high frequency conditions.)
Test Results for the proposed soloution ("peter35" patch (Commit-ID: 5167e8d5417bf5c322a703d2927daec727ea40dd).
.
Experiment and data acquisition details:
.
Control samples with Kernels compiled with CONFIG_NO_HZ=n
.
Kernels without Commit-ID: c308b56b5398779cd3da0f62ab26b0453494c3d
.
Kernels with Commit-ID: c308b56b5398779cd3da0f62ab26b0453494c3d
reported load averages Vs. Actual loads for N processes.
reported load averages Vs. Actual loads for 1 process and various frequencies.
.
Kernel 3.5 RC2 with Commit-ID: 5aaa0b7a2ed5b12692c9ffb5222182bd558d3146
reported load averages Vs. Actual loads for N processes.
.
Kernel with "peter35 patch (Commit-ID: 5167e8d5417bf5c322a703d2927daec727ea40dd)
reported load averages Vs. Actual loads for N processes.
Low Frequency, Low Load, One process.
High Frequency, High Load.
422 Hertz dwell test.
Many PID method test.
.
Ubunru Kernel 3.2.0-29, which contains the backported patches
reported load averages Vs. Actual loads for N processes.
.
Background ("idle") checks
reported load averages background levels.
reported load averages background levels. Kernel 3.2.0-29
background ("idle") reported load histograms with various kernels.
Miscellaneous
reported load averages Vs. Actual loads for N processes - Proposed C. Wang patch.
Compare several kernels reported load averages Vs. Actual loads for 1 and 2 processes.
Some very high sleep frequency results for 3 and 8 processes.
Peter Zijlstra's consume.c program as a text file. With some changes.
|
If you got to this page looking for information on high load averages with Ubuntu Precise Pangolin 12.04 LTS release, then you probably want this page. (If your kernel is very recent, that is probably the page you want, regardless.)
.
2012.08.12 Issues with errors in reported load averages have been fixed in kernel 3.5 and backported to others including 3.2.24 and now ubtuntu 3.2.0-29 #46.
.
2012.06.22 There has been a lot of activity on the Reported Load Averages issues. Some (meaning my part of it) test results for the proposed solution (Commit number: 5167e8d5417bf5c322a703d2927daec727ea40dd).. Slight updates and links added to some other pages.
2012.05.22 This PNG file is very similar to the Linux Reported Load Averages can be too high under light actual loads web page. The PNG file was made for attaching to an e-mail to some kernel.org e-mail lists, where embedded links are undesirable, evidently. It is best viewed at a zoom of 1:1 and scroll down as you look at the graphs and read the text.
2012.05.22 This subject grew beyond the web page that was here. New pages and experiement details are being added. Hopefully you can find what you want from here.
.
These web pages and notes often refer to reported load averages to two decimal places. I agree that is ridiculous. One should only expect, at best, +- 0.1 to 0.15 or +- 10% (whichever is worse), and for the 15 minute average, after settle time. Worse for the shorter time constants.
.
It is hoped that readers understand that the 15 minute reported load average never goes below 0.05 (after it has gone above that value once). A simple finite number of bits integer math issue is the limitation.
Due to their highly sub-sampled nature, the load averages aren't highly accurate anyhow. The overriding requirement for the code is minimal overhead.
An example calculation:
FSHIFT = 11 is the number of bits of precision kept.
EXP_15 = 2037 is the 15 minute filter coefficient (where 2048 = 1.0)
93 = the smallest old load that still scales to 0.05, with rounding.
i.e. 93/2048 = 0.05 to two decimal places.
Now, consider old_15_minute_load_ave = 93 and new load = 0, then we get:
new_15_minute_load_ave = (old * 2037 + load * (2048 - 2037) + a half)/ 2048
= (93 * 2037 + 0 + 1024)/ 2048
= 93
So, in an unloaded system, once the 15 minute load average decays to 0.05 (or 93 as saved internally), it will not decay any further.
Similarly for the 5 minute load average.
|
