From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 9 06:23:48 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B81AC8EB; Tue, 9 Jul 2013 06:23:48 +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 EB1631AA0; Tue, 9 Jul 2013 06:23:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r6965bio065085; Tue, 9 Jul 2013 16:05:38 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 9 Jul 2013 16:05:37 +1000 (EST) From: Ian Smith To: Warren Block Subject: Re: Hyper mode for powerd In-Reply-To: Message-ID: <20130709145722.U61164@sola.nimnet.asn.au> References: <20130707003651.Y26496@sola.nimnet.asn.au> 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: Tue, 09 Jul 2013 06:23:48 -0000 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. > > 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? > > /boot/loader.conf: > hint.p4tcc.0.disabled="1" > hint.acpi_throttle.0.disabled="1" > hw.acpi.cpu.cx_lowest="C3" > > 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? > performance_cx_lowest="Cmax" > performance_cpu_freq="HIGH" > > That grep provides a lot of unrelated "freq" stuff, so here's a guess at what > you want to see: Yes, I tried it on a borrowed Lenovo SL500; lots more than on my T23! > hw.acpi.cpu.cx_lowest: C8 Never heard of C8, but I'm way out of touch with latest hardware. > machdep.acpi_timer_freq: 3579545 > machdep.i8254_freq: 1193182 > machdep.tsc_freq: 3309792585 > dev.cpu.0.freq: 3601 > 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 1600/91000 Interesting specifying 300W right down to 2500MHz before decreasing, and it's quite a large set of primary freqs, only 4 on one 2400MHz Core2Duo. > dev.cpu.0.cx_supported: C1/1/1 C2/2/64 C3/3/96 > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_usage: 31.99% 64.88% 3.12% last 1203us Some changes in -current there. cpu.1.* to cpu.3.* the same as usual, apart from varying cx_usage, so you can safely omit them from reports. [..] > 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 [.. same as freq_levels, without throttling ..] > 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 :) 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? cheers, Ian