An issue with powerd..

[Norberto Meijome]

On Fri, 28 Dec 2007 13:38:13 +1100 (EST)
Ian Smith <smithi at nimnet.asn.au> wrote:

> On Thu, 27 Dec 2007, John Baldwin wrote:

[...]
Hi there :)

>  > It was also far worse in console mode than in X.  In console mode I found that 
>  > sometimes the system would never "come back".
> 
> Presumably X itself keeps it busy enough to keep cpu freq 'reasonable'?
> I use gkrellm to keep an eye on cpu freq, temp, load avg .. but my T23
> is only a two-speed, min 733MHZ, so I can't see what you're seeing (and
> that's my faster laptop :)

hmm not necessarily - all my problems I had with temperature going up and
powerd slowing down the CPU to 100 Mhz were under X. again, the heat issue may
had overriden the 'need for speed'....

> 
>  > So I was running in console mode recently with my timing patches and noticed 
>  > that when it hung it started warning about GPE events taking several 
>  > _seconds_ to process, e.g. 2-3 seconds, or in some cases up to _30_ seconds.  
>  > So, my theory is that powerd has lowered my CPU all the way down to 100mhz 
>  > (easy to reproduce in non-X, just let the box sit with no apps running) and 
>  > that for some reason the machine ends up in a "GPE storm" where it is 
>  > spending all its time handling GPE's and never has any CPU left for userland 
>  > apps (due to being at 100mhz).  The problem then is that powerd never runs to 
>  > bump my CPU up to some reasonable speed.
> 
> One workaround some have noted using is to set debug.cpufreq.lowest to
> some value considerably higher than 100MHz, say >500MHz to maintain
> reasonable responsiveness, at a cost of higher power use when idle.

yes - the only way I could get my machine to work OKish is to set
cpufreq.lowest to 932 Mhz.

> 
>  > In fact, anytime a completely idle box suddently gets a lot of kernel work 
>  > (e.g. a sudden flow of packets) it could in theory end up trying to handle 
>  > all this work at the reduced speed since the work has a higher priority than 
>  > the powerd process.  To that end, I think that at least part of powerd needs 
>  > to be in the kernel, or at least that the kernel should be more proactive 
>  > about bumping the speed up when it resumes from Cx due to an interrupt.  A 
>  > simple policy would be to bump up to full speed for any non-clock interrupt 
>  > (possibly bumping up for a clock interrupt if we wake up softclock as well).
>  > 
>  > Thoughts?
> 
> Just humble grasshopper droppings, master .. but the default powerd
> polling interval is 500ms, which is a really long time on a fast box, so
> -p 100 or even less might make a considerable difference?

giving -p 100 a try now.

> 
> Can't comment on any in-kernel component, but responding per any sort of
> single interrupt/s sounds way too triggerhappy compared to monitoring
> load, assuming that such as vm.loadavg and kern.cp_time are themselves
> updated promptly in high-stress times?
> 
> AU$0.02, which rounds down to 0 since we abandoned coins less than 5c ..

LOL  - good point! 

cheers,
B

_________________________
Norberto Meijome
Octantis Pty Ltd

Exhilaration is that feeling you get just after a great idea hits you,
and just before you realize what is wrong with it.




NOTICE: The contents of this email and its attachments are confidential and
intended only for the individuals or entities named above. If you have received
this message in error, please advise the sender by reply email and immediately
delete the message and any attachments without using, copying or disclosing the
contents. Thank you.