Date: Fri, 08 Apr 2011 18:02:28 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Daniel Gerzo <danger@FreeBSD.org> Cc: stable@FreeBSD.org Subject: Re: powerd / cpufreq question Message-ID: <4D9F2384.5000104@FreeBSD.org> In-Reply-To: <e229a6a374fdd5a626c0b777752fef54@rulez.sk> References: <4D9EEDAF.3020803@rulez.sk> <4D9EF48C.9070907@FreeBSD.org> <e229a6a374fdd5a626c0b777752fef54@rulez.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08.04.2011 17:42, Daniel Gerzo wrote: > On Fri, 08 Apr 2011 14:42:04 +0300, Alexander Motin wrote: >>> root@[s1-a ~]# powerd -v -r 1000 -i 600 >>> powerd: 1000 is not a valid percent >>> >>> Well, that makes sense, but why powerd itself knows about load > 100% >>> but doesn't allow me to specify it? Is this bug? I suppose not if it >>> works for other people... >> >> It is reasonable limitation. powerd can't know how load distributed >> among multiple cores in time. If all cores are equally busy at lets >> say 10% (that gives 120% total) and cores are never waiting for each >> other then obviously frequency could be reduced. But if the same 120% >> mean 100%+20%, or if load is equally spread, but processes on >> different cores are waiting for each other, then reducing frequency >> will reduce performance. powerd can't know that and so stays on a safe >> side. > > OK, I understand what you are saying here. On the other side, I know > pretty well how the load is distributed - in this particular case, the > box is a web server, running ~30 php-cgi processes. > This kind of operation doesn't require very high frequency and I suspect > the cores are never waiting for each other. There could be an option > which would allow an administrator to decide whether this is the case > and allow him to set a higher -r and -i values, what do you think? I think it should be possible with minimal changes. >>> Other question would be why powerd wants to set freq 5336, when it is >>> not available at all (would be nice to have it heh.): >> >> You may see there it is a "wanted" frequency, not real one. :) It is >> internal implementation details. In such way powerd implements keeping >> a full frequency for some time after the load dropped. It's not a bug. > > OK :-) I actually though powerd always honors the values from > dev.cpu.0.freq_levels (and 5336 is not there), so it looked a little > weird to me. It does it on left side, but no longer on the right side. Abstracting from real frequencies made behavior more universal and predictable. >> On multi-core systems like this power management can better be done >> on per-core bases. Powerd can't control frequencies on per-core basis >> (also because it require non-trivial interoperation with scheduler). >> But if your ACPI BIOS allows, you can try to put unused cores into >> deeper C-states, that may give better power saving and TurboBoost on >> busy cores as a bonus. It works better on 9-CURRENT, but on 8-STABLE >> some bonuses still could be achieved. > > Any idea what I should look for in the BIOS? Something about C-states, or Cx-states on the CPU page. But first look at dev.cpu.X.cx_supported to make sure it is not already present and just unused. > This is 8-STABLE, any idea whether there's a MFC plan for the extra > 9-CURRENT bonuses? I suppose around May. >> You may want to look here: >> http://wiki.freebsd.org/TuningPowerConsumption > > From reading this, are you reffering above to the C2 states? (seems > like C3 is not optimal for this kind of operation...) The deeper state, the more power saved. To get most of it and to get TurboBoost working you need at least C3 CPU state (ACPI may report it with different number). Some latest Intel CPUs have no described problems with C3 and LAPIC, for others described system tuning requited. PS: Using powerd in best case wont hurt performance, while using C-states may even increase it in some cases because of TurboBoost. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9F2384.5000104>