From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 6 17:22:25 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E7DC719; Sat, 6 Jul 2013 17:22:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAD11D9A; Sat, 6 Jul 2013 17:22:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r66HMM9q038361; Sun, 7 Jul 2013 03:22:22 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 7 Jul 2013 03:22:22 +1000 (EST) From: Ian Smith To: Warren Block Subject: Re: Hyper mode for powerd In-Reply-To: Message-ID: <20130707003651.Y26496@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 17:22:25 -0000 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