| 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 |