Date: Sat, 08 Nov 2008 06:52:27 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-mobile@FreeBSD.org Subject: Re: RFC: powerd algorithms enhancements Message-ID: <49151B0B.3060308@FreeBSD.org> In-Reply-To: <20081108141418.T70117@sola.nimnet.asn.au> References: <491208D3.2050901@FreeBSD.org> <20081107033524.A70117@sola.nimnet.asn.au> <4914041F.2040101@FreeBSD.org> <20081108141418.T70117@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Smith wrote: > Thanks; I've had a brief browse only so far, but like the approach. > Not sure where you get these 7/8 and 31/32 factors from, and I've no Just empirical. It's just a nice numbers which seem to give good enough results. > hardware to test with lots of freqs, but I'm interested to see how > things like hysteresis under constant but partial load operate (ie > avoiding too much 'hunting' as freq change varies measured load ..) If you will look closer, you will see that there is actually even two hysteresis present. First is the original "idle"/"running" planks. And the second one is the special check on reducing frequency that verifies that estimated load at lower frequency will be less then "running" plank. > > > > 2. To make powerd's operation independent from number and size of frequency > > > > levels I have added internal frequency counter which translated into real > > > > frequencies only on a last stage and only as good as gone. Some systems may > > > > have only several power levels, while mine has 17 of them, so adaptation time > > > > in completely different. It would be good if algorithm was not depending on > > > > it. > > Just for reference, could you show the levels you're working with? dev.cpu.0.freq_levels: 2400/35000 2100/30625 2000/28000 1750/24500 1600/22000 1400/19250 1200/16000 1050/14000 900/12000 800/14000 700/12250 600/10500 500/8750 400/7000 300/5250 200/3500 100/1750 > > > > 3. As part of previous I have changed adaptive mode to rise frequency on > > > > demand up to 2 times and fall on 1/8 per time internal. > > > > > > I'm wondering how the edge case with only 2 freqs would go? Eg on my > > > T23, single cpu P3 Mobile at 1133 and 733MHz. That is, I'm wondering if > > > your 1/8 factor might better be scaled to no. of cpus and/or no. of > > > freqs available? I'd best say no more until studying your algorithm .. > > > > I have not such case, but I think there should be no problem. > > Ok .. just to confirm I'm reading it right: you wind up using the first > table freq BELOW the calculated desired freq, right? So with my case of > 1133 & 733, if at 1133 and coming down, 7/8 * 1133 = 991, so select 733? No. I am using frequency equal or above to desired. So ad 991 I will still select 1133. 733 will be set only after 4 steps: 1133*7/8 => 991 991*7/8 => 867 867*7/8 => 758 758*7/8 => 733 > > Move configuration from command line into configuration file will allow > > more customized profiles to be written, so if somebody wants to - he may > > do it. For trivial command line configuration this solution looks like > > appropriate. > > Sure. I do want to get to that, though C is mostly read-only for me, > and there's still way too much I know way too little about :) but with > modern laptops it's clear that just telling people to enable powerd > isn't cutting it anymore, especially with the sort of issues people are > seeing with systems dropping back to ridiculously low cpu freqs - like > perhaps the default cpufreq.lowest ought to be initially set no lower > than perhaps 1/8 of full speed, out of the box, to mitigate such issues? Huge latency on low frequencies was actually that reason why I have started this work. Now with new exponential algorithms and reduced polling interval I am no longer experiencing any problems. Defining minimal CPU frequency is a completely wrong way IMO as it will not allow to really use all power management abilities. The main goal of the exponential frequency reducing, which I have implemented, was to increase time interval before setting lowest frequency. In my case, while working at 2400MHz, powerd will drop 300MHz per single 1/4s interval, but it will take 1.5s of completely idle CPU to drop from 200MHz to 100MHz on batteries and 5s on AC-power! -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49151B0B.3060308>