Summary: The proposed patch is very good for improved Reported Load Average accuracy over most conditions.
It does slightly worse under higher number of running processes, higher load per process conditions, but plenty good enough.
Introduction: This page merely presents test results of the Linux Reported Load Averages accuracy improvement patch "peter35" (Commit-ID: 5167e8d5417bf5c322a703d2927daec727ea40dd), and re-presents similar test results from previous tests for comparision.
The patch was written by Peter Zijlstra, one of the kernel.org maintainers of the related area of code. Charles Wang was a contributor, suggesting code solutions, but also orginally spotting the defects in the current code. Yong Zhang pointed out a slight error an earlier version of Peter's patch code. Thanks to all for their hard work on this one.
This web page will not dwell on the history and other test results, as covered by other pages ( here and here ), but some previous results are repeated herein.
Legend: Throughout this document, some abbreviations are used:
Control: older kernel compiled with CONFIG_NO_HZ=n
c308: Kernel with the earlier commit c308b56b5398779cd3da0f62ab26b0453494c3d4
5aaa: Basically, Kernel 3.5 RC2, with commits: 556061b00c9f2fd6a5524b6bde823ef12f299ecf and 5aaa0b7a2ed5b12692c9ffb5222182bd558d3146
Wang: Charles Wang's first proposed solution.
Peter35: Peter Zijlstra's current proposed solution. Commit-ID: 5167e8d5417bf5c322a703d2927daec727ea40dd
Some of these patchs were backcoded into my test environment, Ubuntu server edition 12.04, Kernel 3.2.0-24-generic #39. The server is behind on updates, because I never make changes while working on these type of issues.
Where available (i.e. where I have done it), some graphs can be "clicked" on to go to a more detailed write up of the experiment that provided the plotted data
Compare various Kernels, 1 and 2 processes: 180 Hertz total sleep frequency (180 hertz for the one process case and 90 hertz each for the two process case). All data has been extracted from various "Reported Load Averages Vs. Actual Loads for N processes" tests.
Reported Load Averages Vs. Actual Loads for N processes:
First, an example that would be typical with any of recent commits:
Next, the with the proposed solution:
High Load, High Sleep Frequency A.K.A. (Also Known As) the Charles Wang or Tao Ma failure senario.
Low frequency, low load: (there is some sub-testing on going within the writeup page (2012.06.25))
Dwell test: A multi-hour look at reported load averages
First, an example that would be typical with any of recent commits, but was actually done with an old old proposed patch:
Next, the with the proposed solution:
Notice the significant reduction in the noise level on the 1 min reported load average. The two significant "dips" in reported load averages are interesting and perhaps worth further investigation.
The second "dip" is a 14% drop in the 15 minute average at elapsed time 06:09:19 and time of day 06:20:46
A simple test with an older test method of many PIDs over time: (If I can remember how to do it.)
First, an example that would be typical with any of recent commits, but was actually done with an old old proposed patch:
Next, the with the proposed solution:
Background check:
Note: 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.
Sanity checks:
A simple check of some 100% program, without all this fancy sleep stuff. This worked as expected.
A simple check of some program with a significant amount of I/O wait time. I wrote a program that read bytes from random locations in a big file (i.e. spent most of it time seeking). It worked as expected in terms of reported load averages including the uninterruptable sleep (the IO wait ) times.
References:
The main thread that lead to the proposed patch.
Another thread.
The actual patch as a text file.