From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933047AbXBLHKE (ORCPT ); Mon, 12 Feb 2007 02:10:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933053AbXBLHKD (ORCPT ); Mon, 12 Feb 2007 02:10:03 -0500 Received: from comtv.ru ([217.10.32.17]:49721 "EHLO comtv.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933047AbXBLHJv (ORCPT ); Mon, 12 Feb 2007 02:09:51 -0500 X-UCL: actv Date: Mon, 12 Feb 2007 10:10:09 +0300 (MSK) From: malc X-X-Sender: malc@home.oyster.ru To: Con Kolivas cc: linux-kernel@vger.kernel.org Subject: Re: CPU load In-Reply-To: <200702121712.50168.kernel@kolivas.org> Message-ID: References: <8cd998d50702112144y38958d27saec4196f6f5d5236@mail.gmail.com> <200702121712.50168.kernel@kolivas.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.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 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