Re: powerd(8)

From: Kevin Oberman <oberman_at_es.net>
Date: Mon, 18 Apr 2005 16:29:44 -0700
> From: "Poul-Henning Kamp" <phk_at_phk.freebsd.dk>
> Date: Mon, 18 Apr 2005 14:27:53 +0200
> Sender: owner-freebsd-current_at_freebsd.org
> 
> In message <2304.1113826754_at_critter.freebsd.dk>, "Poul-Henning Kamp" writes:
> >In message <4263A33A.3030201_at_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
> _at__at_ -50,6 +50,7 _at__at_
>  enum modes_t {
>  	MODE_MIN,
>  	MODE_ADAPTIVE,
> +	MODE_PHK,
>  	MODE_MAX,
>  };
>  
> _at__at_ -220,6 +221,8 _at__at_
>  		*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);
>  }
> _at__at_ -377,6 +380,37 _at__at_
>  		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_at_ 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_at_es.net			Phone: +1 510 486-8634
Received on Mon Apr 18 2005 - 21:29:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:32 UTC