All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: malc <av1474@comtv.ru>
Cc: Con Kolivas <kernel@kolivas.org>, linux-kernel@vger.kernel.org
Subject: Re: CPU load
Date: Mon, 26 Feb 2007 10:28:37 +0100	[thread overview]
Message-ID: <20070226092837.GB3790@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.64.0702251334200.17241@linmac.oyster.ru>

Hi!

> [..snip..]
> 
> >>The current situation ought to be documented. Better yet some flag
> >>can
> >
> >It probably _is_ documented, somewhere :-). If you find nice place
> >where to document it (top manpage?) go ahead with the patch.
> 
> 
> How about this:

Looks okay to me. (You should probably add your name to it, and I do
not like html-like markup... plus please don't add extra spaces
between words)...

You probably want to send it to akpm?
								Pavel

> <Documentation/load.txt>
> 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:
> 
> <transcript>
> $ 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
> 
> ...
> </transcript>
> 
> 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)
> </Documentation/load.txt>
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2007-02-26  9:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-12  5:33 Vassili Karpov
2007-02-12  5:44 ` Con Kolivas
2007-02-12  5:54   ` malc
2007-02-12  6:12     ` Con Kolivas
2007-02-12  7:10       ` malc
2007-02-12  7:29         ` Con Kolivas
2007-02-12  5:55   ` Stephen Rothwell
2007-02-12  6:08     ` Con Kolivas
2007-02-12 14:32   ` Pavel Machek
2007-02-13 22:01     ` malc
2007-02-13 22:08       ` Con Kolivas
2007-02-14  7:28         ` malc
2007-02-14  8:09           ` Con Kolivas
2007-02-14 20:45           ` Pavel Machek
2007-02-25 10:35             ` malc
2007-02-26  9:28               ` Pavel Machek [this message]
2007-02-26 10:42                 ` malc
2007-02-26 16:38                   ` Randy Dunlap
2007-02-12 18:05   ` malc
  -- strict thread matches above, loose matches on Subject: below --
2018-03-27 11:44 CPU Load Ryan Meulenkamp
2018-03-29  1:24 ` Andre McCurdy
2018-03-29  6:42   ` Jussi Laako
2007-02-12 16:57 CPU load Andrew Burgess
2007-02-12 18:15 ` malc
2002-07-10 14:50 David Chow
2002-07-10 16:54 ` William Lee Irwin III
2002-07-10 17:49   ` Robert Love
2002-07-26 17:38     ` David Chow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070226092837.GB3790@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=av1474@comtv.ru \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: CPU load' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.