linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: malc <av1474@comtv.ru>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: CPU load
Date: Mon, 12 Feb 2007 10:10:09 +0300 (MSK)	[thread overview]
Message-ID: <Pine.LNX.4.64.0702121006030.1049@home.oyster.ru> (raw)
In-Reply-To: <200702121712.50168.kernel@kolivas.org>

On Mon, 12 Feb 2007, Con Kolivas wrote:

> On Monday 12 February 2007 16:54, malc wrote:
>> On Mon, 12 Feb 2007, Con Kolivas wrote:
>>> On 12/02/07, Vassili Karpov <av1474@comtv.ru> wrote:
>>
>> [..snip..]
>>
>>> The kernel looks at what is using cpu _only_ during the timer
>>> interrupt. Which means if your HZ is 1000 it looks at what is running
>>> at precisely the moment those 1000 timer ticks occur. It is
>>> theoretically possible using this measurement system to use >99% cpu
>>> and record 0 usage if you time your cpu usage properly. It gets even
>>> more inaccurate at lower HZ values for the same reason.
>>
>> Thank you very much. This somewhat contradicts what i saw (and outlined
>> in usnet article), namely the mplayer+/dev/rtc case. Unless ofcourse
>> /dev/rtc interrupt is considered to be the same as the interrupt from
>> PIT (on X86 that is)
>>
>> P.S. Perhaps it worth documenting this in the documentation? I caused
>>       me, and perhaps quite a few other people, a great deal of pain and
>>       frustration.
>
> Lots of confusion comes from this, and often people think their pc suddenly
> uses a lot less cpu when they change from 1000HZ to 100HZ and use this as an
> argument/reason for changing to 100HZ when in fact the massive _reported_
> difference is simply worse accounting. Of course there is more overhead going
> from 100 to 1000 but it doesn't suddenly make your apps use 10 times more
> cpu.

Yep. This, i belive, what made the mplayer developers incorrectly conclude
that utilizing RTC suddenly made the code run slower, after all /proc/stat
now claims that CPU load is higher, while in reality it stayed the same -
it's the accuracy that has improved (somewhat)

But back to the original question, does it look at what's running on timer
interrupt only or any IRQ? (something which is more in line with my own
observations)

-- 
vale

  reply	other threads:[~2007-02-12  7:10 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 [this message]
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
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=Pine.LNX.4.64.0702121006030.1049@home.oyster.ru \
    --to=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).