From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 9 18:40:13 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 E9B25E93; Tue, 9 Jul 2013 18:40:13 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9572C12F6; Tue, 9 Jul 2013 18:40:13 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r69IeCle047392; Tue, 9 Jul 2013 12:40:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r69IeBvm047389; Tue, 9 Jul 2013 12:40:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 9 Jul 2013 12:40:11 -0600 (MDT) From: Warren Block To: Ian Smith Subject: Re: Hyper mode for powerd In-Reply-To: <20130709145722.U61164@sola.nimnet.asn.au> Message-ID: References: <20130707003651.Y26496@sola.nimnet.asn.au> <20130709145722.U61164@sola.nimnet.asn.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 09 Jul 2013 12:40:12 -0600 (MDT) 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: Tue, 09 Jul 2013 18:40:14 -0000 On Tue, 9 Jul 2013, Ian Smith wrote: > On Sat, 6 Jul 2013 20:09:46 -0600, Warren Block wrote: > > On Sun, 7 Jul 2013, Ian Smith wrote: > > > > > 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. > > > > It may do that, but if so it's doing it more quickly than is visible running > > powerd -a hyper -n hyper -v. > > Apart from some possible under-the-hood adjustment by thermal control in > an over-temperature situation (?) and /etc/rc.d/power_profile poking the > freq on AC/battery changes (not applicable to yours), as far as I know > the only thing that adjusts freqs is powerd itself. So no, it's not > hunting for you. But then, due to you having disabled p4tcc and > acpi_throttle, your lowest speed is 1600, only 1/2.25 x 3600, a far cry > from the up to 32:1 sort of ranges seen with p4tcc etc enabled. > > What I'm concerned about is what happens engaging your hyper mode with > out-of-the-box settings, ie with p4tcc or acpi_throttle enabled as by > default. Would you care to find out? :) I have no means to do so. > > /boot/loader.conf: > > hint.p4tcc.0.disabled="1" > > hint.acpi_throttle.0.disabled="1" > > hw.acpi.cpu.cx_lowest="C3" Commenting those entries out gives: dev.cpu.0.freq_levels: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1750/142625 1600/91000 1400/79625 1200/68250 1000/56875 800/45500 600/34125 400/22750 200/11375 dev.est.0.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 With only that change and powerd running in hyper mode, it subjectively feels slower to start things. > > I've routinely used the first two since first reading about them, I think in > > another post by Kevin. > > Indeed, Kevin's been chewing on this bone for quite some time :) but I > don't know if there's any PR + simple patch that may attract attention? > I also don't know if the situation is the same on AMD CPUs, or others. > > > /etc/rc.conf: > > powerd_flags="-a hyper -n hyper" > > Still on 9.1 at least, > #define DEFAULT_ACTIVE_PERCENT 75 > #define DEFAULT_IDLE_PERCENT 50 > #define DEFAULT_POLL_INTERVAL 250 /* Poll interval in milliseconds */ > > So hyper mode will select max freq if load at 1600MHz is > 75/4 = 18.75% > after 250mS. I use 200mS and there's no impact on powerd CPU usage even > at my idle 733MHz; your responsiveness may benefit from using say 100mS? Interesting point. 100mS is a perceptible lag. It occurs to me that CPU load is really a poor predictor of what is happening on an interactive session. powerd ought to have a wakeup signal. On a keypress or mouse move or some other type of user input, powerd would jump to the highest frequency of the current profile. It does not matter as much how it decides to drop back down. Using devd to switch powerd profiles would be interesting. powerd would have to be able to switch profiles while running, I think. Maybe startup cost is not that high. > > This is an i5, with the "3601" being turbo mode. > > With that beast I'm amazed you can really notice slower responsiveness > w/ 4 CPUs @ 1600MHz, but then I get by with a P3-M at 1133/733MHz :) Some would say I'm more particular about it than most people. I just say I want it faster. :) > It would be interesting to see cpu.0.freq_levels, est.0.freq_settings > and the p4tcc.0 settings - and whether it hunts - with default tuning on > some sort of lightish load - perhaps a big find like on the daily runs? Timing 'periodic daily' now with a full cache and powerd not running: 995.53 real 28.15 user 132.17 sys With 'powerd -a hyper -n hyper -v > /tmp/powerd.log': 2322.06 real 58.72 user 305.22 sys Load varied enough that it would drop to 200MHz quite often. Picking a random part of the log: load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 11%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 10%, current freq 200 MHz (26), wanted freq 200 MHz load 4%, current freq 200 MHz (26), wanted freq 200 MHz now operating on AC power; changing frequency to 3601 MHz load 55%, current freq 200 MHz (26), wanted freq 3601 MHz changing clock speed from 200 MHz to 3601 MHz now operating on AC power; changing frequency to 200 MHz load 4%, current freq 3601 MHz ( 0), wanted freq 200 MHz changing clock speed from 3601 MHz to 200 MHz load 4%, current freq 200 MHz (26), wanted freq 200 MHz now operating on AC power; changing frequency to 3601 MHz load 20%, current freq 200 MHz (26), wanted freq 3601 MHz changing clock speed from 200 MHz to 3601 MHz now operating on AC power; changing frequency to 200 MHz load 3%, current freq 3601 MHz ( 0), wanted freq 200 MHz changing clock speed from 3601 MHz to 200 MHz load 4%, current freq 200 MHz (26), wanted freq 200 MHz now operating on AC power; changing frequency to 3601 MHz load 21%, current freq 200 MHz (26), wanted freq 3601 MHz changing clock speed from 200 MHz to 3601 MHz now operating on AC power; changing frequency to 200 MHz load 0%, current freq 3601 MHz ( 0), wanted freq 200 MHz