Date: Fri, 14 Nov 2008 12:26:45 +0200 From: Alexander Motin <mav@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Sam Leffler <sam@freebsd.org>, freebsd-mobile@freebsd.org Subject: Re: RFC: powerd algorithms enhancements Message-ID: <491D5265.3020003@FreeBSD.org> In-Reply-To: <200811131606.24804.jhb@freebsd.org> References: <200811060901400000@466321507> <200811131145.39747.jhb@freebsd.org> <491C9380.7050007@FreeBSD.org> <200811131606.24804.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> 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. > The solution is to move the > one bit of userland code that is needed into the kernel. In this case I'm > not suggesting moving all of powerd into an interrupt handler. What I am > suggesting is that the kernel needs a policy to consider raising the > frequency when it gets an interrupt after being in a deep sleep. If the > power savings from C2/3/whatever are greater than running throttled, then it > is much more ideal when you get an interrupt while idle that you run at full > speed to service the interrupt and then return to C2/C3 ASAP rather than > running the interrupt handler at a throttled speed and spending less time in > C2/C3. C2 does not give visible benefit to me against EST+C1E. C3 and deeper (which suspends the bus) theoretically could, but at this moment they are not working on SMP systems due to APIC timer problem, so IMHO we should better manage it first. Also for interrupt case modern CPUs specially does not getting out of C2/3/... states completely. You can read about that in C2D datasheet. CPU tries to avoid frequency/voltage rise for short times. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?491D5265.3020003>