RFC: powerd algorithms enhancements

[John Baldwin]

On Friday 14 November 2008 05:26:45 am Alexander Motin wrote:
> John Baldwin wrote:
> > On Thursday 13 November 2008 03:52:16 pm Alexander Motin wrote:
> >> 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!
> > 
> > I think systems are more complex than you give them credit for.  Imagine 
what 
> > CPU frequency changing does to SMI# handlers for example.
> 
> You may be right, I am sure not very good in some hardware aspects, but
> neither EST, nor throttling affect system bus operation. I don't see
> direct relation there, it could easily be just some
> hardware/acpi/whatever bug.

Well, some more details are that I occasionally see one of the GPE handlers on 
my laptop take 750ms (milli-seconds, not micro-seconds) to run at full CPU 
speed.  If I ever close the lid and then raise it, then I will see one of 
these every few seconds (I added debugging printfs to output the time 
for "long-running" GPEs to my kernel previously to debug this and they are 
still there; saw them again this morning).  They only take up 0.7% of my CPU 
when they run at full speed.  However, when I drop down from 1867 to, say, 
100, then each one now takes several seconds, and with them coming in every 
few seconds, it ends up live-locking the system, even though at full CPU 
speed it is < 1% CPU every 5 seconds or so.

> >> 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.
> > 
> > I'm not advocating moving the entire system into interrupt handlers.  Did 
you 
> > actually read what I wrote?  My point is that if you have something in 
> > userland that is as important as what gets done in interrupt handlers, the 
> > solution is to not rip up the entire scheduler to make certain bits of 
> > userland have a higher priority than interrupts.
> 
> All I wanted to say is that CPU frequency should not be so important for
> system operation. Yes, system will be slower and more latent at lower
> frequency, but is must be responsible. Scheduler must be able to give
> every process (even user-level) it's time quantum.

Well, but the problem is that it is that important.  The scheduler is 
responsible for managing the resource known as the "CPU", and we obviously 
stick the scheduler in the kernel. :)  It's not really userland's job to 
ensure that kernel-level tasks have enough CPU horsepower to execute.

-- 
John Baldwin