Date: Mon, 11 Feb 2008 23:41:35 +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: <47B0C10F.6000109@icyb.net.ua> In-Reply-To: <47A33CCB.3090902@icyb.net.ua> References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 01/02/2008 17:37 Andriy Gapon said the following:
> on 29/01/2008 19:31 Nate Lawson said the following:
>> Andriy Gapon wrote:
>>> Report for 7.0-RC1 on quite old hardware: 440BX-based motherboard,
>>> 450Mhz Pentium III (Katmai).
>>>
>>> cx_supported claims to support C1, C2, C3. If I set cx_lowest to C3 it
>>> immediately gets backed out to C2 with a kernel message about too many
>>> short sleeps. But that's not a problem.
>>> 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 ?
>>> If not, does this indicate some problem in idle routine or is this just
>>> incorrect statistics calculation ? Or maybe something with HW ?
>> Leave it at C1. Apparently C2 and C3 don't work on your machine.
>> That's understandable with older, non-laptop hw.
>
> Nate,
>
> I understand the advice. I event see that the code has the following
> comment "Disable C3 support for all PIIX4 chipsets", but apparently it
> does a little bit different thing.
>
> 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.
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.
I briefly looked at their sources and it seems that they have a little
bit more quirks for this chipset. On the other hand I am not sure if
they have any relevance here: I see that "type-F DMA" is disabled and
our code in acpi_cpu.c uses "flush" method instead of bus master control.
http://lxr.linux.no/linux/drivers/acpi/processor_idle.c#L389
http://lxr.linux.no/linux/drivers/acpi/processor_core.c#L171
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B0C10F.6000109>