Date: Thu, 13 Nov 2008 00:40:34 +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: <491B5B62.40609@FreeBSD.org> In-Reply-To: <200811111206.53809.jhb@freebsd.org> References: <200811060901400000@466321507> <491319C0.8090201@freebsd.org> <49132585.4070601@FreeBSD.org> <200811111206.53809.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > 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. If your system completely freezes at 400MHz, then it spends about 20% of CPU time on this at 2GHz. Doesn't it? With such amount of idle activity you system just unable to save any power! Your 100% running CPU at 400MHz will probably consume more power then any other really idle at 2GHz. If you think that this is normal then disabling powerd is the only way out for you. >> 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. No. It only hides the problem. >> 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. Can you show me this strategy to work in context? There was no significant changes at powerd for years. Now it does not works fine for SMP, it does not works fine for systems with big number of power levels, it's functionality is absolutely minimal. That's why I have touched it. There is several good ideas of future improvement was proposed, but nobody give me any real objections against what I have proposed. All of your objections is that your system unable to operate at low frequency. So how it is related to powerd and proposed patches? Here is how I see possible strategy: - Give more information to power controlling application: Differentiate between power level and throttling. Throttling is completely ineffective for CPUs supporting C1E, C2 and deeper states. It will give us better responsibility at equal power consumption. - Make scheduler to use some per-CPU power state priorities to allow us really disable unused cores/chips. - Reduce interrupt time to allow scheduler better handle process priorities and fight against IRQ livelocks. It does not depends on frequencies. What is your strategy vision? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?491B5B62.40609>