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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 used 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 just added an option to powerd to do a linear backoff instead which seems smoother to me since I only had a limited number of steps (although I just discovered if I load cpufreq.ko I get a lot more.. doh.. thought I'd already done that :) > http://www-mtl.mit.edu/research/icsystems/pubs/conferences/2001/sinha_vlsi2 >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 system will respond slowly to workload changes. However you could use 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 speed is that if it drops down to a really low speed after some idle time it could take a very long time to get some CPU time. Not sure if it's a real problem yet though. -- 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCVIqk5ZPcIHs/zowRAojBAJ9pA5Bh+r68TW4kN4BItN90DLuEXgCgj5Ld vbOTF+YbC+Yetelu+AJk54E= =MB26 -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504071049.32854.doconnor>