|  | ======== | 
|  | CPU load | 
|  | ======== | 
|  |  | 
|  | Linux exports various bits of information via ``/proc/stat`` and | 
|  | ``/proc/uptime`` that userland tools, such as top(1), use to calculate | 
|  | the average time system spent in a particular state, for example:: | 
|  |  | 
|  | $ iostat | 
|  | Linux 2.6.18.3-exp (linmac)     02/20/2007 | 
|  |  | 
|  | avg-cpu:  %user   %nice %system %iowait  %steal   %idle | 
|  | 10.01    0.00    2.92    5.44    0.00   81.63 | 
|  |  | 
|  | ... | 
|  |  | 
|  | Here the system thinks that over the default sampling period the | 
|  | system spent 10.01% of the time doing work in user space, 2.92% in the | 
|  | kernel, and was overall 81.63% of the time idle. | 
|  |  | 
|  | In most cases the ``/proc/stat``	 information reflects the reality quite | 
|  | closely, however due to the nature of how/when the kernel collects | 
|  | this data sometimes it can not be trusted at all. | 
|  |  | 
|  | So how is this information collected?  Whenever timer interrupt is | 
|  | signalled the kernel looks what kind of task was running at this | 
|  | moment and increments the counter that corresponds to this tasks | 
|  | kind/state.  The problem with this is that the system could have | 
|  | switched between various states multiple times between two timer | 
|  | interrupts yet the counter is incremented only for the last state. | 
|  |  | 
|  |  | 
|  | Example | 
|  | ------- | 
|  |  | 
|  | If we imagine the system with one task that periodically burns cycles | 
|  | in the following manner:: | 
|  |  | 
|  | time line between two timer interrupts | 
|  | |--------------------------------------| | 
|  | ^                                    ^ | 
|  | |_ something begins working          | | 
|  | |_ something goes to sleep | 
|  | (only to be awaken quite soon) | 
|  |  | 
|  | In the above situation the system will be 0% loaded according to the | 
|  | ``/proc/stat`` (since the timer interrupt will always happen when the | 
|  | system is executing the idle handler), but in reality the load is | 
|  | closer to 99%. | 
|  |  | 
|  | One can imagine many more situations where this behavior of the kernel | 
|  | will lead to quite erratic information inside ``/proc/stat``:: | 
|  |  | 
|  |  | 
|  | /* gcc -o hog smallhog.c */ | 
|  | #include <time.h> | 
|  | #include <limits.h> | 
|  | #include <signal.h> | 
|  | #include <sys/time.h> | 
|  | #define HIST 10 | 
|  |  | 
|  | static volatile sig_atomic_t stop; | 
|  |  | 
|  | static void sighandler (int signr) | 
|  | { | 
|  | (void) signr; | 
|  | stop = 1; | 
|  | } | 
|  | static unsigned long hog (unsigned long niters) | 
|  | { | 
|  | stop = 0; | 
|  | while (!stop && --niters); | 
|  | return niters; | 
|  | } | 
|  | int main (void) | 
|  | { | 
|  | int i; | 
|  | struct itimerval it = { .it_interval = { .tv_sec = 0, .tv_usec = 1 }, | 
|  | .it_value = { .tv_sec = 0, .tv_usec = 1 } }; | 
|  | sigset_t set; | 
|  | unsigned long v[HIST]; | 
|  | double tmp = 0.0; | 
|  | unsigned long n; | 
|  | signal (SIGALRM, &sighandler); | 
|  | setitimer (ITIMER_REAL, &it, NULL); | 
|  |  | 
|  | hog (ULONG_MAX); | 
|  | for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog (ULONG_MAX); | 
|  | for (i = 0; i < HIST; ++i) tmp += v[i]; | 
|  | tmp /= HIST; | 
|  | n = tmp - (tmp / 3.0); | 
|  |  | 
|  | sigemptyset (&set); | 
|  | sigaddset (&set, SIGALRM); | 
|  |  | 
|  | for (;;) { | 
|  | hog (n); | 
|  | sigwait (&set, &i); | 
|  | } | 
|  | return 0; | 
|  | } | 
|  |  | 
|  |  | 
|  | References | 
|  | ---------- | 
|  |  | 
|  | - http://lkml.org/lkml/2007/2/12/6 | 
|  | - Documentation/filesystems/proc.txt (1.8) | 
|  |  | 
|  |  | 
|  | Thanks | 
|  | ------ | 
|  |  | 
|  | Con Kolivas, Pavel Machek |