Date: Mon, 18 Apr 2005 16:01:17 +0200 From: Bruno Ducrot <ducrot@poupinou.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Eric Anderson <anderson@centtech.com> Subject: Re: powerd(8) Message-ID: <20050418140117.GH2298@poupinou.org> In-Reply-To: <2304.1113826754@critter.freebsd.dk> References: <4263A33A.3030201@centtech.com> <2304.1113826754@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 18, 2005 at 02:19:14PM +0200, Poul-Henning Kamp wrote: > 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. The full speed thing is right in almost case. When we ran the processor at lower speed, then we loose somehow the runpercent if running at full speed at previous window. Suppose for example we have those normalized performance states: 100% 66% 50% If we ran at 50% but read a 100% runpercent, then if we were running at full speed, we would got a 50% runpercent which is given by (runpercent * normalized_speed). Those far, we can only say actually that runpercent (at full speed) is in-between 50% and 100%. If, for example, the real runpercent (at full speed) is actually 50%, then we should stay at 50%, if its at 66%, we should set speed at 66% and so on. But we can only estimate a value of 50% in all cases. Therefore almost all algorithms will put the processor at full speed if an increase is detected. This work pretty well when the polling intervall is small (something between 40 or 50 milliseconds). In the case of powerd, the real trouble is maybe the polling interval and we should use an adaptive filter in order to fix this issue. The case when we detect to go down is less problematic because we are able to compute at least an accurate estimation of runpercent for the previous window. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050418140117.GH2298>