[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47053FC7.2070308@redhat.com>
Date: Thu, 04 Oct 2007 15:32:23 -0400
From: Chuck Ebbert <cebbert@...hat.com>
To: Luca Tettamanti <kronos.it@...il.com>
CC: Frans Pop <elendil@...net.nl>, Willy Tarreau <w@....eu>,
LKML <linux-kernel@...r.kernel.org>,
Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
"Alexander E. Patrakov" <patrakov@....usu.ru>
Subject: Re: Decreasing stime running confuses top
On 10/04/2007 03:19 PM, Luca Tettamanti wrote:
>>>>>> The latter seems to be utime ...decreasing. No wonder if
>>>>>> arithmetics will give strange results (probably top is using
>>>>>> unsigned delta?)...
>>>>> Hmm, minor miscounting from my side, stime seems more appropriate...
>>>> So, is it normal that stime decreases sometimes or a kernel bug?
>>>> /me expects the last...
>>> Let me guess... Dual core AMD64 ?
>> Nope: Intel(R) Pentium(R) D CPU 3.20GHz
>
> I just notice the same thing here, with a Core2 Duo (which is supposed
> to have synced TSCs) and working HPET.
>
>> The following may well be relevant.
>> With 2.6.22 and early 2.6.23-rc kernels (rc3-rc6) I often had this in my
>> kernel log (see http://lkml.org/lkml/2007/9/16/45):
>> checking TSC synchronization [CPU#0 -> CPU#1]:
>> Measured 248 cycles TSC warp between CPUs, turning off TSC clock.
>> Marking TSC unstable due to check_tsc_sync_source failed
>
> I don't see this though, TSCs are always syncronized between the 2
> cores.
>
Is CONFIG_VIRT_CPU_ACCOUNTING set?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists