Date: Tue, 11 Nov 2008 12:06:53 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-mobile@freebsd.org Cc: Alexander Motin <mav@freebsd.org>, Sam Leffler <sam@freebsd.org> Subject: Re: RFC: powerd algorithms enhancements Message-ID: <200811111206.53809.jhb@freebsd.org> In-Reply-To: <49132585.4070601@FreeBSD.org> References: <200811060901400000@466321507> <491319C0.8090201@freebsd.org> <49132585.4070601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 06 November 2008 12:12:37 pm Alexander Motin wrote: > 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. On my laptop the ACPI SCI is the culprit. If I let the CPU drop below 400 mhz, the GPE handler for temperature updates takes so long to run the CPU spends the entire time processing GPEs and never runs userland. Thus, powerd never gets to run. This happens on a "modern" laptop, not a Pentium-100. And actually, at certain speeds it would eventually let userland run enough to bump up. I actually added KTR_SCHED events for ACPI GPE and Task handling and hacked schedgraph to parse them and thus had pretty pictures showing the GPE handler using all CPU time during the multiple-second "hangs" I would get on my laptop with powerd. > 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. It will definitely fix the problem on my laptop. > 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. The point is that powerd is part of a CPU throttling strategy. If you are going to mess with powerd you need to do so in the context of the overall strategy. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811111206.53809.jhb>