[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2.6.17-rc3: cpufreq-set -g ondemand does not work

Ben, Michael,

On Wed, May 17, 2006 at 08:15:42AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2006-05-16 at 14:54 +0200, Michael Schmitz wrote:

> > > "JoseJX" write there that ondemand and conservative cannot be used
> > > on 7xx/74xx processors because of the time required to switch speeds.
> > 
> > The reason seems to be a rather conservative assumption on the latency
> > ('probably takes forever') - does it really take more than 10 ms to switch
> > speeds? The code path on the 7447A models appears to have a settle delay
> > of 1 ms after the feature call (which boils down to an OUTB, basically),
> > another 0.1 ms after the low_choose_7447a_dfs call which shouldn't take
> > very long either. Am I missing something, Ben?
> I'm being over conservative bcs of the voltage change
> > I'd not be surprised if the latency was as low as 2 ms total - can we
> > profile this reliably in some way? I guess I'll just set the latency to 5
> > ms and see what happens ...
> Last time I looked the on-demand governor was using a workqueue...
> anything that has a latency of more than a few dozen usec in a workqueue
> shall be shot...

you are talking over my head here,
but my idea would be that an ondemand govenor would just work
on a load average with some delay to even out spikes.
Why not raise that delay and have no problem?

I my simplistic world I would expect the kernel to have such an option
as this is very close to the core. If the user wants more sofisticated
algorithms, this is very real user space daemons come in.

Am I completey off the mark here?

Attachment: pgprn7RH4ZvkV.pgp
Description: PGP signature

Reply to: