Date: Sun, 29 Mar 2009 13:19:54 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: powerd broken Message-ID: <49CF595A.30805@bsdforen.de> In-Reply-To: <49CF615A.6050304@FreeBSD.org> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Motin wrote:
> Dominic Fandrey wrote:
>> Alexander Motin wrote:
>>> Dominic Fandrey wrote:
>>>> Alexander Motin wrote:
>>>>> Dominic Fandrey wrote:
>>>>>> Since I updated to the 7.2 prerelease, powerd is broken.
>>>>>>
>>>>>>> uname -a
>>>>>> FreeBSD mobileKamikaze.norad 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE
>>>>>> #0:
>>>>>> Tue Mar 24 07:57:30 CET 2009
>>>>>> root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b
>>>>>> amd64
>>>>>>
>>>>>> It increases the CPU frequency very aggressively in adaptive mode.
>>>>>> That means full speed with a system load below 1%. I have to use the
>>>>>> following nonsensical powerd_flags to make it work sensibly:
>>>>>> -a adaptive -b minimum -i 95 -r 99
>>>>>>
>>>>>> The system is a Core2 Duo, if that is of any help.
>>>>> Run powerd in foreground with -v option to get it's work trace. If it
>>>>> reaches full speed, there must be some reason to do it.
>>>>>
>>>>> Updated powerd indeed may behave a bit more aggressively
>>>>> (especially in
>>>>> new hiadaptive mode, default for AC power). But it was made several
>>>>> months ago and nobody have complained yet. I am personally using it on
>>>>> 8-CURRENT on my Core2Duo laptop every day.
>>>>>
>>>> # grep powerd /etc/rc.conf
>>>> powerd_enable="YES"
>>>> #powerd_flags="-a adaptive -b minimum -i 95 -r 99"
>>>> powerd_flags="-a adaptive -b minimum -v"
>>>> # rcrestart powerd powerd not running?
>>>> Starting powerd.
>>>> powerd: using sysctl for AC line status
>>>> powerd: using devd for AC line status
>>>> load 77%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>>>> load 74%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>>>> load 78%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>>>> load 79%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>>>> load 65%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>>>> load 72%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>>>> load 76%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>>>> ...
>>>>
>>>> The real load was between 3 and 7 % while these were recorded.
>>>>
>>>> Note that I use the normal/old adaptive mode.
>>> Reason is not in algorithm. Reason is in reporting so high load
>>> (65-79%). Run this test please at the same conditions to understand
>>> what's going on there:
>>>
>>> sysctl kern.cp_times && sleep 1 && \
>>> sysctl kern.cp_times && sleep 1 && \
>>> sysctl kern.cp_times && sleep 1 && \
>>> sysctl kern.cp_times
>>>
>>
>> Measurings done with cpu speed set to 800MHz with ~6% CPU load.
>>
>> # while sleep 1; do sysctl kern.cp_times; done
>> kern.cp_times: 27709 1 14989 900764 1019830 122302 0 34956 2705 1802746
>> kern.cp_times: 27711 1 14989 900835 1019891 122308 0 34959 2705 1802871
>> kern.cp_times: 27711 1 14991 900914 1019944 122316 0 34960 2705 1802996
>> kern.cp_times: 27712 1 14993 900992 1019997 122328 0 34966 2705 1803112
>>
>> A more convinient output:
>> # oldtimes=$(sysctl -n kern.cp_times); while sleep 1; do
>> times=$(sysctl -n kern.cp_times); for time in $times; do printf "%8s"
>> $(($time - ${oldtimes%% *})); oldtimes=${oldtimes#* }; done; echo;
>> oldtimes=$times; done
>> 0 0 3 66 64 10 0 3
>> 0 121
>> 1 0 3 78 56 7 0 8
>> 0 122
>> 1 0 4 64 68 23 0 4
>> 0 111
>> 2 0 2 85 56 7 0 12
>> 0 126
>
> It means that one of your CPUs spent most of it's time in interrupt
> processing and so far from idle. What does `top -P` shows you? Where
> have you seen that ~6% CPU load?
>
That is the load shown by the e17 CPU module. It's display has always
been in sync with top in the past, no longer though, it appears.
# top -PIS
last pid: 68235; load averages: 0.09, 0.16, 0.17 up 0+05:17:29 13:05:10
137 processes: 4 running, 117 sleeping, 16 waiting
CPU 0: 1.1% user, 0.0% nice, 1.1% system, 61.4% interrupt, 36.3% idle
CPU 1: 9.0% user, 0.0% nice, 3.4% system, 0.0% interrupt, 87.6% idle
Mem: 419M Active, 415M Inact, 416M Wired, 3752K Cache, 183M Buf, 716M Free
Swap: 4096M Total, 4096M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 1 171 ki31 0K 16K RUN 1 286:42 93.46% idle: cpu1
23 root 1 -80 - 0K 16K RUN 0 126:54 59.96% irq16: hdac0 uhci+
12 root 1 171 ki31 0K 16K RUN 0 179:27 40.09% idle: cpu0
1318 root 1 46 0 439M 312M select 1 12:55 1.76% Xorg
4361 musicpd 4 44 0 91164K 14412K ucond 1 1:57 0.78% mpd
Some things strike me as odd. The difference between the load reported
by powerd and top is still very significant and of course the high
interrupt load.
I've got a mouse with a 1khz report rate (the only connected USB
device), but unplugging it doesn't change the load. Neither does
stopping moused (I'm running the system without HAL). There also
is a fingerprint reader, but it is only detected by ugen.
Thanks for all your time, I really appreciate that.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49CF595A.30805>