On Tuesday 20 Apr 2010 01:47:02 Arjan van de Ven wrote: > > > > One idea I had but a) never had time to implement it and b) was > > > > not sure it would be accepted anyway, was to modify ondemand > > > > governor to ramp up instantly, but slow down slowly (in a > > > > configurable way). > > > > > > that's what ondemand does already. > > > > How and where in the code and how to enable that behaviour? From my > > experiments frequency goes down to minimum as soon as load goes away. > > What I was talking about is gradual lowering over a configurable > > period. It is not power efficient, but it could be good for latency > > in some workloads. > > it's not even good for that ;-( > > it's better then to stay high longer... at least on modern machines the > inbetween states are pretty much either useless or actually energy > hurting compared to the higher state. Why do you think it is not good for latency to stay at higher frequency for longer? I had a machine until recently with a relatively slow Turion64 which had 800Mhz minimum and 1.8Ghz maximum frequency states. With ondemand governor when web browsing for example, frequency would drop to 800Mhz as soon as scrolling or such stopped, and then was pushed back up to max on user interaction. Overall experience was sluggish, but when switching to performance governor it was much much better. That is why I proposed to have a gradual lowering as an option in on-demand. You said it already does that - I ask are you sure? And also now you are saying it would not be good for latency - above is an example when it clearly does help (a lot). Would this idea of gradual lowering help for the "git grep" use case as well? To me it sounds better than taking IO wait into account. What happens with your scheme with a pure IO load? Ok, you say power use is not determined by frequency, fine, but it sounds slightly wrong to max the frequency on pure IO wait. If frequency per se really does not waste power then gradual lowering could both "git grep" and my web browsing latency use case, what do you think? Tvrtko Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
