Date: Thu, 7 Apr 2005 10:49:25 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: freebsd-hackers@freebsd.org Cc: Bruno Ducrot <ducrot@poupinou.org> Subject: Re: My experience with cpufreq in -STABLE Message-ID: <200504071049.32854.doconnor@gsoft.com.au> In-Reply-To: <20050406140102.GY2298@poupinou.org> References: <200504041645.j34Gj2ow002999@pinky.frank-behrens.de> <200504060649.j366nGQg021228@pinky.frank-behrens.de> <20050406140102.GY2298@poupinou.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1592994.Ac9TFyuyFi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 6 Apr 2005 23:31, Bruno Ducrot wrote: > On Wed, Apr 06, 2005 at 08:49:15AM +0200, Frank Behrens wrote: > > Bruno Ducrot <ducrot@poupinou.org> wrote on 4 Apr 2005 19:17: > > > You may start looking at src/usr.sbin/powerd in -current, and improve > > > it a bit? The actual algorithm used in powerd may need some rework > > > IMHO. > > > > Which problems do you see? > > powerd use an exponentional decrease of the frequency. This might be > not stable for certain workload. The algorithm used by the acpi_ppc module semed quite good to me when I use= d=20 it (before the frequency stuff was committed). http://www.spa.is.uec.ac.jp/~nfukuda/software/index.html I have been meaning to get around to adding it to powerd.. For the moment I= =20 just added an option to powerd to do a linear backoff instead which seems=20 smoother to me since I only had a limited number of steps (although I just= =20 discovered if I load cpufreq.ko I get a lot more.. doh.. thought I'd alread= y=20 done that :) > http://www-mtl.mit.edu/research/icsystems/pubs/conferences/2001/sinha_vls= i2 >001.pdf > > and it seems it's maybe not the better one, though (search 'MAW', its > exactly what you suggest). That paper is interesting reading :) > > 2. The default polling time of 500 ms seems to be very short. It can > > increased to several seconds. > > Problem if you increase teh polling intervall is that you can't be sure > that the system can detect in time when going up. I don't think increasing the poll interval is a good idea - it means your=20 system will respond slowly to workload changes. However you could use=20 filtered averages (a la that paper) to reduce the number of speed changes. One thing that does worry me about having a userland daemon control the spe= ed=20 is that if it drops down to a really low speed after some idle time it coul= d=20 take a very long time to get some CPU time. Not sure if it's a real problem= =20 yet though. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1592994.Ac9TFyuyFi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCVIqk5ZPcIHs/zowRAojBAJ9pA5Bh+r68TW4kN4BItN90DLuEXgCgj5Ld vbOTF+YbC+Yetelu+AJk54E= =MB26 -----END PGP SIGNATURE----- --nextPart1592994.Ac9TFyuyFi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504071049.32854.doconnor>