Date: Wed, 10 Jul 2013 20:05:56 +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: <20130710200113.J23480@sola.nimnet.asn.au> In-Reply-To: <alpine.BSF.2.00.1307091058280.46436@wonkity.com> References: <alpine.BSF.2.00.1307041955110.10280@wonkity.com> <20130707003651.Y26496@sola.nimnet.asn.au> <alpine.BSF.2.00.1307062000220.45491@wonkity.com> <20130709145722.U61164@sola.nimnet.asn.au> <alpine.BSF.2.00.1307091058280.46436@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Jul 2013 12:40:11 -0600, Warren Block wrote: > 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: [..] > > 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 Right, cpufreq has added 1750, 1400, 1200, 1000, 800, 600, 400 and 200, the latter being 1/8 of the lowest absolute freq of 1600, due to p4tcc. That's a range of 18:1, not as bad as 32:1 but still quite a lot. You may find it instructive (though once is probably enough :) to set debug.cpufreq.verbose=1 in loader and watch cpufreq working out which freqs to use from those available. It does prefer absolute freqs, but still uses the relative freqs to setup the lower freqs. There's also debug.cpufreq.lowest, but messing with that requires custom tuning. > With only that change and powerd running in hyper mode, it subjectively feels > slower to start things. At 1/8 the speed, that's not too surprising .. [..] > > > /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. Maybe just. On that beast I think you could use 50ms with no noticeable powerd CPU usage, maybe even 25ms. In fact I think doing just that with hadp mode might get you all the interactive responsiveness you want, and still let powerd use a range of freqs as required. Playing with -r and -i will also alter the responsiveness curve quite a bit. With it then testing load and increasing frequency 5 times as often, on full load it should shift up 5 times more quickly, and hadp mode already shifts freq up by a factor of 4 on each poll_interval, so it should get from 1600 to 3601 in one! iteration, and even if using p4tcc/throttling, from 200 to 3601 in only two or three steps (200 x 4 = 800, 800 x 4 = 3200) with even three steps then taking only 150ms, well inside your current 250ms interval. Maybe give that a try? > 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. You're talking about some pretty major kernel hacking, apart from powerd in userland. Maybe getting devd to notify on every keypress and mouse click (mouse movement would be insanely busy) but I think that'd be OTT and get you in far deeper water than you want, I suspect :) > 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. At the moment powerd uses devd notification for AC/battery state changes only. It's using select() with the poll_ival timeout, so it gets those devd events as they occur, otherwise it times out after the poll_ival then tests load vs freq, adjusts if necessary, then back to select(). > > > 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. :) Testing load every 50ms should be fast enough. If not, powerd will accept down to 5ms for poll_interval, but that seems excessively busy. The only disadvantage might be extreme verbosity in -v mode :) > > 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 Hunting away. Over twice as long to run. Maybe now try at 50ms in hadp mode and you'll have a good idea how fast that runs, and how it feels. cheers, Ian (wishing momentarily I had one like yours to play with :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130710200113.J23480>