RFC: powerd algorithms enhancements

[Alexander Motin]

Sam Leffler wrote:
> Alexander Motin wrote:
>>> The biggest problem I see with powerd is that when a system is 
>>> running with a reduced clock frequency interrupts are not processed 
>>> at full clock speed.  This, for example, breaks the ath driver which 
>>> can generate interrupts very quickly when  h/w MIB counters overflow 
>>> in a noisy environment.  Because processing happens at the reduced 
>>> frequency until powerd gets to run it causes livelock
>>
>> You wanted to say that ath driver/hardware unable to operate on slow 
>> CPUs? Ok, but may be it is an ath driver problem? May be it must use 
>> some kind of interrupt moderation to avoid it?
> 
> You didn't understand me.  I used ath as an example of the general problem.

I understand you. The real problem I see here is that any hardware 
interrupts now can livelock the system. It is not limited to ath. Big 
packet rate on any fast enough interface that has any significant 
receive processing is able to make system not responding, just because 
interrupts will consume all available CPU time.

powerd just makes that situation more probable as it significantly 
reduces CPU performance. Just insert gigabit card into Pentium-100 
system and you will not be able to get there onder the load of only did 
not using device polling mode. Rising frequency on interrupt processing 
_will_not_ fix the problem, but just hide it for some time, until newer 
network cards will be able to handle higher packet rate.

I think the only solutions for this case can be in allowing scheduler to 
really do it's job. Or by moving _everything_ out of interrupt threads 
to make them extremely fast and so to avoid the livelock problem, or in 
some other way allow scheduler to delay interrupt processing to allow 
other (for example user-level) threads to obtain at least some part of 
their CPU time slot according to their priorities.

I don't see how powerd itself could do at least anything with this.

-- 
Alexander Motin