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
next prev parent reply other threads:[~2007-02-26 9:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-12 5:33 CPU load 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 --
2007-02-12 16:57 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 \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).