Date: Sun, 7 Jul 2013 03:22:22 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Warren Block <wblock@wonkity.com> Cc: acpi@freebsd.org, Kevin Oberman <rkoberman@gmail.com>, wblock@freebsd.org Subject: Re: Hyper mode for powerd Message-ID: <20130707003651.Y26496@sola.nimnet.asn.au> In-Reply-To: <alpine.BSF.2.00.1307041955110.10280@wonkity.com> References: <alpine.BSF.2.00.1307041955110.10280@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Jul 2013 30:12:12 -0600, Warren Block wrote:
> Attached is a proposed patch for -head that adds a "hyper" mode to powerd.
> Instead of slewing like the adaptive modes, this mode drops all the way to
> the lowest frequency when the system is idle, and jumps all the way to the
> highest frequency when there is any load.
>
> Subjectively, it seems more responsive for desktop use than hiadaptive mode.
> That's hard to benchmark. Power usage is another question. This mode might
> use less power than the adaptive modes, but that's also difficult to
> benchmark.
>
> Comments welcome.
I'll get to what Kevin talks about later, but want to address this in
the context of how most modernish systems will run without deliberate
tuning, that is with both absolute (eg est, powernow, acpi_perf) and
relative (eg p4tcc, acpi_throttle) freq drivers enabled as shipped, see
cpufreq(4) - though it may be somewhat out of date these days.
Kevin is on the money, I believe, about the relative drivers; they add
freqs of 7/8 down to 1/8 in 12.5% steps of a base absolute frequency,
but offer little or no power savings over the base freq, keep the same
CPU voltage and frequency, merely dropping between 1 and 7 out of every
8 cycles (to put it simply), by design to control excessive temperature.
cpufreq merely treats these extra frequencies as equivalent in value to
the primary, absolute levels, perhaps two to half a dozen from est /
powernow, which shift both voltage and frequency, and there's nothing
powerd can do to control - or even distinguish? - added relative freqs.
We've often seen lately freq_levels ranging from say 2400 down to 75MHz,
a range of 32:1, using the absolute levels plus all possible rates in
between from the relative drivers. It's far from an exact science, most
often I/O or network speed will be big factors, but it's perhaps fair to
speculate that a process keeping a CPU (more likely CPUs) at 75MHz let's
say 50% busy / 50% idle, is going to be something like only 1/32 as busy
cranked up to 2400MHz - maybe less than 2% busy.
Looking at your patch, 'scuse trimming and tab loss,
+ if (load > cpu_running_mark / 4) {
+ freq = freqs[0];
+ if (curfreq != freq) {
+ if (vflag) {
[..]
+ }
+ idle = 0;
+ if (set_freq(freq) != 0) {
[..]
+ }
+ }
+ } else {
+ freq = freqs[numfreqs - 1];
+ if (curfreq != freq) {
+ if (vflag) {
[..]
+ }
+ idle = 0;
+ if (set_freq(freq) != 0) {
[..]
+ }
+ }
+ }
So even if cpu_running_mark were 100% (-r100), anything busier than 25%
of our example 75MHz would shift to maximum freq immediately, where the
load will likely plummet to just a few percent, way less than the 25%
(at -r100) needed to keep it at that freq; ie it will most likely hunt.
You don't appear to be taking any notice of the -i idle percentage here;
perhaps that would be a more useful shift-down criterion? Even so, with
a full house of frequencies, I can't see this being easy to tune as is.
Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on?
And your powerd_flags setting?
Of course anyone having a large number of freqs down to very slow could
mitigate that by setting debug.cpufreq.lowest (or powerd's -m switch) to
something more sensible, perhaps 300MHz or so, but even then it might be
wise to chose an absolute rather than relative rate. If you disable
p4tcc and throttling, you'll see how many absolute levels your CPU runs,
and you may find using only those with hadp mode satisfies your needs?
No argument this stuff is difficult to benchmark, even without the near
infinite variety of possible workload scenarios, and apart from mav@'s
power measurements with various things tuned or disabled, I've seen very
little in the way of real data over the years.
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130707003651.Y26496>