From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 23:29:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8148816A4CE for ; Mon, 18 Apr 2005 23:29:45 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0587443D5C for ; Mon, 18 Apr 2005 23:29:45 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Mon, 18 Apr 2005 16:29:43 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 271AD5D07; Mon, 18 Apr 2005 16:29:44 -0700 (PDT) To: "Poul-Henning Kamp" In-reply-to: Your message of "Mon, 18 Apr 2005 14:27:53 +0200." <2428.1113827273@critter.freebsd.dk> Date: Mon, 18 Apr 2005 16:29:44 -0700 From: "Kevin Oberman" Message-Id: <20050418232944.271AD5D07@ptavv.es.net> cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 23:29:45 -0000 > From: "Poul-Henning Kamp" > Date: Mon, 18 Apr 2005 14:27:53 +0200 > Sender: owner-freebsd-current@freebsd.org > > In message <2304.1113826754@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > >In message <4263A33A.3030201@centtech.com>, Eric Anderson writes: > >>Lukas Ertl wrote: > >> > >>There's been some discussion on the -mobile list (I believe) about > >>this kind of thing before. I think powerd is currently running with > >>a 'best shot' configuration, and I'm pretty sure that if anyone has > >>a better algorithm in a patch form for people to try, I'm certain the > >>good people with commit bits would easily commit a patched better version. > > > >I don't think a proportional approach will work in this case, the steps > >are too far apart. > > > >I also think the switch to full speed is wrong. Such see-saw > >algorithms waste far too much time decaying. A less steep flank > >should be used. > > > >For instance: > > > > if (idle > 90%) > > reduce clock one step. > > if (idle < 80%) > > increase clock two steps. > > Here's a patch which implements "phk" mode: > > > Index: powerd.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/powerd/powerd.c,v > retrieving revision 1.4 > diff -u -r1.4 powerd.c > --- powerd.c 27 Feb 2005 01:58:49 -0000 1.4 > +++ powerd.c 18 Apr 2005 12:26:03 -0000 > @@ -50,6 +50,7 @@ > enum modes_t { > MODE_MIN, > MODE_ADAPTIVE, > + MODE_PHK, > MODE_MAX, > }; > > @@ -220,6 +221,8 @@ > *mode = MODE_MAX; > else if (strcmp(arg, "adaptive") == 0) > *mode = MODE_ADAPTIVE; > + else if (strcmp(arg, "phk") == 0) > + *mode = MODE_PHK; > else > errx(1, "bad option: -%c %s", (char)ch, optarg); > } > @@ -377,6 +380,37 @@ > if (read_usage_times(&idle, &total)) > err(1, "read_usage_times"); > > + if (mode == MODE_PHK) { > + for (i = 0; i < numfreqs - 1; i++) { > + if (freqs[i] == curfreq) > + break; > + } > + if (idle < (total * cpu_running_mark) / 100 && > + curfreq < freqs[0]) { > + i -= 2; > + if (i < 0) > + i = 0; > + if (vflag) { > + printf("idle time < %d%%, increasing clock" > + " speed from %d MHz to %d MHz\n", > + cpu_running_mark, curfreq, freqs[i]); > + } > + if (set_freq(freqs[i])) > + err(1, "error setting CPU frequency %d", freqs[i]); > + } else if (idle > (total * cpu_idle_mark) / 100 && > + curfreq > freqs[numfreqs - 1]) { > + i++; > + if (vflag) { > + printf("idle time > %d%%, decreasing clock" > + " speed from %d MHz to %d MHz\n", > + cpu_idle_mark, curfreq, freqs[i]); > + } > + if (set_freq(freqs[i])) > + err(1, "error setting CPU frequency %d", freqs[i]); > + } > + continue; > + } > + > /* > * If we're idle less than the active mark, jump the CPU to > * its fastest speed if we're not there yet. If we're idle Virtually identical in function to the code I posted to acpi@ when powerd first was added to current, except that it is better written than mine was. Thanks, PHK. I also have found that changing the polling interval to 150 is an improvement. Half a second is just too long, IMHO. I also discovered that with my system (P4M) that some settings can use substantially more power than faster settings, so I have kludged an ugly hack to avoid those settings. These changes make a significant difference in power consumption. Unfortunately my day job has had me too busy to do much work on it of late. I'm on vacation next week and will a) get a lot of time to play with it or b) not touch it because my wife gets annoyed by my spending vacation on a computer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634