RFC: powerd algorithms enhancements

[Alexander Motin]

John Baldwin wrote:
>> If your system completely freezes at 400MHz, then it spends about 20% of 
>> CPU time on this at 2GHz. Doesn't it?
> 
> Nope.  It is usually very idle at full speed.  You are free to go buy your own 
> HP nc6220 if you want to see it for yourself.  You can also grab the KTR 
> trace and modified schedgraph.py at www.freebsd.org/~jhb/gpe/.

It's very strange to me that you have 100% load at 400MHz, but zero at 
full speed. It shouldn't be so!

Just an idea. I have noticed a problem, that my mobile Core2Duo does not 
drops TSC timer frequency on EST. It confuses kernel time counting and 
leads to incorrect proportional increasing of DELAY() times. I have 
fixed this problem to myself with "kern.timecounter.invariant_tsc=1". 
Can't it just be applicable to your CPU?

>>>> 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.
> 
> This is completely backwards.  Userland is not more important than interrupt 
> handling in the kernel.  The problem is that CPU frequency handling is more 
> important than relegating the entire task to userland.  Instead of completely 
> breaking the entire userland/kernel model to get part of userland executed at 
> a kernel-level priority so CPU frequency handling is partially handled at a 
> kernel-level priority, why not just move the CPU frequency bits that need to 
> be kernel-level into the kernel?  We already doing the thermal management for 
> passive cooling in the kernel rather than in userland.

The fact of system livelocks means that interrupt processing works out 
of any priorities! Saying that moving all processing into interrupt 
handlers is a good way, you are saying that having _all_ our system out 
of any priorities is a good idea. That's actually the situation we are 
able to see now with heavy network load with polling disabled. System 
just dies and there is no other way to manage that except enabling polling!

Heavy interrupt handlers is _evil_ from the scheduling point of view! It 
may be faster in some situations, but it makes system unmanageable! 
There are never will be enough power to fulfill all requirements, so we 
must take care about the case when there will be more interrupts then we 
are able to handle.

-- 
Alexander Motin