Date: Fri, 07 Nov 2008 11:05:03 +0200 From: Alexander Motin <mav@FreeBSD.org> To: FreeBSD acpi <freebsd-acpi@freebsd.org> Subject: RFC: powerd algorithms enhancements Message-ID: <491404BF.1090807@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
The discussion of this is going on mobile@: -------- Original Message -------- Subject: RFC: powerd algorithms enhancements Date: Wed, 05 Nov 2008 22:57:55 +0200 From: Alexander Motin <mav@FreeBSD.org> To: freebsd-mobile@FreeBSD.org Hi. I would like to propose the patch for powerd that fixes some issues, makes it more universal and on my opinion more usable. The main ideas of mine were: 1. To make it more SMP polite. Previous version uses average CPU load that leads to the often load underestimation. It make powerd with default configuration unusable on systems with more then 2 CPUs. I propose to use summary load instead of average one. IMO this is the best we can do without specially tuned scheduler. Also as soon as measuring total load on SMP systems is more useful then total idle, I have switched to it. 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. 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. 4. For desktop (AC-powered) systems I have added one more mode - "hiadaptive". It rises frequency twice faster, drops it 4 times slower, prefers twice lower CPU load and has additional delay before leaving the highest frequency after the period of maximum load. This mode was specially made to improve interactivity of the systems where operation capabilities are more significant then power consumption, but keeping maximum frequency all the time is not needed. 5. I have reduced polling interval from 1/2 to 1/4 of second. It is not important for algorithm math now, but gives better system interactivity. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?491404BF.1090807>