Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Feb 2008 11:56:10 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        Nate Lawson <nate@root.org>
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: cx_lowest and CPU usage
Message-ID:  <47B4103A.6090902@icyb.net.ua>
In-Reply-To: <47B0C10F.6000109@icyb.net.ua>
References:  <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
on 11/02/2008 23:41 Andriy Gapon said the following:
> on 01/02/2008 17:37 Andriy Gapon said the following:
>>> Andriy Gapon wrote:
>>>> Report for 7.0-RC1 on quite old hardware: 440BX-based motherboard,
>>>> 450Mhz Pentium III (Katmai).
[snip]
>>>> There is a weird thing: if I change cx_lowest to C2 when the machine is
>>>> completely idle, top shows that CPU usage for interrupts immediately
>>>> jumps to almost 20%. Change cx_lowest to C1, CPU usage drops back to
>>>> almost 0%.
>>>> Is this normal ?
[snip]

I mis-reported the issue. Actually the above behavior occurs if I
throttle CPU 50% (via acpi throttling) and I am not concerned about this
at all.

C2 has even stranger effects.
On almost idle system, with cx_lowest=C1, top reports about 0-2% user,
0% nice, 0-2% system, 1-2% interrupt, 94-98% idle.
After changing cx_lowest to C2, I see the following: 0-2% user, 0% nice,
0-2% system, 94-98% interrupt, 1-2% idle.

It's as if idle and interrupt stats were switched!
But I am sure it is not that simple.

Next, hardware monitoring doesn't show any change in parameters, CPU
temperature stays the same.
vmstat -i doesn't show any change in interrupt rates.
top -S shows that system 'idle' process is a top CPU consumer with
almost 100% WCPU.
This leads me to assume that indeed some statistics miscalculation or
misattribution occurs.

I am not familiar with scheduling, idling and "cpu accounting" code, so
I couldn't have a slightest idea how/why this happens. It's if the acpi
idling was done in some interrupt thread.

Out of curiosity I hacked kern_clock.c, statclock() a little bit to
report on kernel thread/process that takes a lot of iticks and it seems
that td->td_proc->p_pid is 12.
With ps I see that idle process has pid 11 and pid 12 belongs to the
following:
[swi4: clock sio]
(btw, this machine has serial ports but nothing is connected)

Not sure if this information has any value.
As I understand software clock interrupt is used to run things scheduled
via timeout(), so it might be a variety of things that get run.


Just in case, here's a little bit of sysctl output:
dev.cpu.0.freq: 448
dev.cpu.0.freq_levels: 448/-1 224/-1
dev.cpu.0.cx_supported: C1/0 C2/90
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_usage: 1.71% 98.28%


>> Out of curiosity, what could be wrong with C2 state ?
>> vmstat -i reports identical interrupt rates with both cx_lowest=C1 and
>> cx_lowest=C2, so I wonder where from the extra interrupt CPU utilization
>> comes.
[snip]
> I do realize that I am talking about a quite minuscule problem with very
> old hardware and the problem is related to quirks, but anyway.
> I tried Knoppix LiveCD (built on Linux kernel 2.6.18) and it shows that
> states C1 and C2 are available. Also, when C2 is allowed ("active") it
> doesn't exhibit high interrupt usage behavior as our kernel does.
[snip]

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B4103A.6090902>